Как выбрать, внедрить и использовать автоматизированные сканеры уязвимостей: советы для организаций любого масштаба.
- Введение
- Аудитория и структура
- Преимущества сканирования уязвимостей
- Соотношение с ручным тестированием
- 1. Оценка текущих программ управления уязвимостями
- Какие функции нужны?
- 2. Идентификация активов
- 3. Выбор подходящего типа сканера уязвимостей
- Сравнительный анализ: Инфраструктурные сканеры vs Сканеры веб-приложений
- 4. Выбор модели развертывания
- 5. Определение активов для сканирования и времени его проведения
- Дополнительные критерии выбора
Введение
Сканирование уязвимостей – это широкий термин, используемый для описания автоматизированного процесса выявления недостатков в программе защиты организации. Он охватывает такие сферы, как процесс управления патчами, процедуры усиления защиты и жизненный цикл разработки программного обеспечения (SDLC). Сервисы или продукты, предлагающие функции сканирования уязвимостей, также часто называют системами оценки уязвимостей (vulnerability assessment systems, VAS).
В рамках эффективной программы управления уязвимостями (vulnerability management programme, VMP) решения для сканирования могут стать доступным способом автоматического выявления проблем с безопасностью в сетях организации.
Однако рынок таких продуктов охватывает множество специализированных ниш и предлагает широкий спектр вариантов, отличающихся, в частности, моделями развертывания и стоимостью лицензий. Из-за этих нюансов бывает сложно сделать правильный выбор в контексте собственной организации.
Данная статья предоставляет необходимые советы для выбора подходящего решения для сканирования уязвимостей.
Аудитория и структура
Эта статья поможет предприятиям малого и среднего бизнеса, крупным организациям и учреждениям государственного сектора:
- понять основы сканирования уязвимостей и его интеграцию с программой управления уязвимостями (VMP);
- определить, когда и как наиболее эффективно применять сканирование уязвимостей;
- сформировать ключевые критерии при приобретении решения для сканирования.
Статья разделена на четыре этапа. Начиная с оценки текущей системы сканирования уязвимостей, после чего рассматривается выбор необходимого типа сканера. Далее анализ, что именно и когда следует сканировать, а в завершение – несколько общих рекомендаций.
Преимущества сканирования уязвимостей
Существует несколько причин, почему организациям стоит пользоваться преимуществами сканирования уязвимостей:
- Автоматизация: сканирование можно запускать по расписанию, по требованию или в ответ на определенные триггерные события (например, сборка новой версии программного продукта или развертывание нового сервера). Это позволяет постоянно поддерживать актуальную картину ландшафта уязвимостей.
- Скорость: обычно сканеры выполняют сотни или даже тысячи проверок значительно быстрее, чем это было бы возможно при ручном тестировании.
- Экономическая эффективность: благодаря скорости и автоматизации проводить сканирование целевых систем значительно выгоднее, чем тестировать их вручную.
- Масштабируемость: современные облачные архитектуры позволяют сервисам динамически увеличивать или уменьшать объем вычислительных ресурсов. Благодаря этому сканирование как малых, так и крупных сред занимает примерно одинаковое время.
- Комплаенс: многие решения для сканирования уязвимостей содержат специализированные проверки, позволяющие оценить соответствие общепринятым стандартам информационной безопасности или собственному базовому набору средств контроля организации.
- Точность: выполняя целенаправленные проверки для подтверждения наличия уязвимостей, сканеры обеспечивают гораздо более надежные результаты, чем простая ссылка на данные из решений для управления программными активами.
Но самое важное то, что сканирование уязвимостей позволяет организации не отставать от лиц и группировок, стремящихся скомпрометировать системы, ведь многие из них используют похожие инструменты и методы для поиска пробелов в безопасности.
Соотношение с ручным тестированием
Стоит отметить, что автоматизированное сканирование уязвимостей не может сравниться с ручными процессами, такими как тестирование на проникновение, когда речь идет о широте и глубине охвата тестированием.
Вместо этого автоматизированное сканирование следует рассматривать как экономически эффективный способ выявления и управления типичными проблемами безопасности без необходимости привлекать узкопрофильных специалистов по тестированию.
В то же время, устраняя наиболее очевидные и легкие цели с помощью регулярного сканирования уязвимостей, во время тестирования на проникновение специалисты смогут эффективнее сосредоточиться на более сложных угрозах безопасности, анализ которых требует именно человеческого интеллекта.
1. Оценка текущих программ управления уязвимостями
Сканирование уязвимостей эффективно снижает риски для организации только тогда, когда оно используется как часть более широкой программы управления уязвимостями (VMP).
VMP обычно включают следующие процессы:
- Обнаружение систем: идентификация IТ-активов, принадлежащих организации.
- Классификация активов: распределение активов на группы или категории на основе общих характеристик.
- Выявление уязвимостей: поиск и валидация уязвимостей в активах.
- Приоритизация уязвимостей: определение приоритетности уязвимостей в соответствии с техническими или бизнес-целями.
- Устранение уязвимостей: предоставление рекомендаций по исправлению выявленных проблем и проверка результатов устранения.
- Раскрытие информации об уязвимостях: обеспечение механизма, с помощью которого исследователи безопасности могут сообщать о найденных уязвимостях.
Решения для сканирования уязвимостей часто содержат функции, которые поддерживают VMP или интегрируются с ней, например:
- Обнаружение систем: регулярное сканирование для поиска новых хостов в пределах нужного диапазона (или диапазонов) IP-адресов или новых веб-приложений.
- Валидация систем: сверка обнаруженных систем с имеющимися записями в базах управления активами.
- Адаптация отчетности: настройка формата представления отчетов об уязвимостях таким образом, чтобы они соответствовали приоритетам бизнеса или организации.
- Поддержка процесса устранения: повторное сканирование конкретных проблем и автоматическое оповещение после того, как их исправление будет подтверждено.
- Интеграция с другими системами: взаимодействие с системой отслеживания ошибок или репозиториями исходного кода для координации и автоматизации рабочих процессов.
- Обеспечение безопасного доступа: предоставление защищенного портала с аутентификацией, где пользователи могут авторизоваться для совместной работы над управлением уязвимостями.
Какие функции нужны?
То, насколько наличие этих функций повлияет на выбор решения для сканирования уязвимостей, зависит от текущей программы управления уязвимостями (VMP): повысят ли они эффективность процессов, или лишь создадут лишнее усложнение.
Например, организации, в которой еще не внедрена VMP, пригодится сервис с централизованным порталом, который позволит различным администраторам просматривать и управлять уязвимостями в своих зонах ответственности (собственных системах).
В свою очередь, компаниям со зрелой и отлаженной VMP такой функционал, вероятно, уже доступен. Поэтому им может быть вполне достаточно продукта с поддержкой экспорта результатов для легкой интеграции с их текущими решениями.
Другие функции, на которые стоит обратить внимание при приобретении сканера уязвимостей, подробно описаны в конце этой статьи.
2. Идентификация активов
Термин «актив» в контексте сканирования уязвимостей используется для определения сущности (физической или виртуальной), с которой связаны уязвимости. В зависимости от типа проводимого сканирования, активы могут иметь различные формы, например:
- компонент сетевой инфраструктуры, такой как роутер или свитч;
- подключенный виртуальный или физический хост, например, ноутбук, периферийное устройство или сервер;
- экземпляр веб-платформы или приложения;
- облачные хосты или конечные точки.
Обычно организации владеют разнообразными активами, охватывающими некоторые или все из перечисленных категорий, хотя определенные типы могут преобладать над другими. Важно, чтобы эти активы были идентифицированы и задокументированы (в идеале в реестре активов), что позволит подобрать наиболее подходящий тип (или типы) сканера уязвимостей.
Оценка затрат
Многие поставщики взимают плату за свои услуги по сканированию по принципу «за каждый актив», поэтому для оценки затрат перед закупкой критически важно иметь точное представление о количестве активов. Этого можно достичь с помощью инструментов для сканирования портов (часто доступных бесплатно), которые позволяют найти активные хосты в сети.
Части IТ-инфраструктуры могут оказаться сильно распределенными, например, из-за того, что пользователи работают удаленно со своих собственных мобильных устройств. В таких случаях целесообразно сосредоточиться на общих сервисах, предназначенных для удаленного доступа с этих устройств. Например, когда пользователям необходимо авторизоваться на едином веб-портале или сервере виртуальной частной сети (VPN), который доступен извне. Хотя безопасность конечных устройств, находящихся вне периметра внутренней сети, остается важной, удаленное сканирование уязвимостей вряд ли принесет пользу при таких обстоятельствах. Вместо этого защита удаленных устройств от распространенных уязвимостей должна обеспечиваться путем своевременного обновления программного обеспечения.
После идентификации всех релевантных активов организации их следует разделить на отдельные логические группы. Например, можно выделить все серверные хосты или веб-приложения, связанные с главным сайтом, в одну категорию, а парк внутренних рабочих станций – в другую. Это поможет определить отдельные, более удобные для администрирования области охвата для каждого отдельного сканирования уязвимостей.
Как отмечалось выше в разделе по оценке текущей программы управления уязвимостями, некоторые решения поддерживают этот процесс, автоматически выполняя обнаружение и классификацию систем.
3. Выбор подходящего типа сканера уязвимостей
Обычно сканеры уязвимостей классифицируют в соответствии с типом целевых систем, для оценки которых они предназначены. Наиболее широкое разделение происходит на решения для «инфраструктуры» и для «приложений».
В свою очередь, сканеры приложений делятся на те, которые проверяют веб-приложения, и те, которые ориентированы на нативные приложения. Также существуют инструменты для ряда специализированных подкатегорий, таких как облачная инфраструктура, мобильные приложения или веб-приложения, созданные с использованием определенной платформы или технологии.
Хотя специализированные сканеры могут предоставлять наиболее точные и релевантные результаты для тех типов целевых систем, на которые они рассчитаны, IТ-инфраструктура организации обычно имеет слишком большое разнообразие, чтобы такие решения могли самостоятельно обеспечить комплексное покрытие. Поэтому сначала лучше наладить базовый уровень общего сканирования, чтобы обеспечить надлежащий уровень выявления самых распространенных инфраструктурных проблем.
Если организация имеет открытые активы в других специфических категориях (например, упомянутых выше), а бюджет это позволяет, рекомендуется применять многоуровневый подход к сканированию. Он заключается в дополнении базового сканирования более специализированными инструментами.
Сканеры инфраструктуры
Решения для сканирования инфраструктуры обычно сосредоточены на выявлении и тестировании сервисов, которые доступны для остальной сети или интернета в целом. Для этого они часто содержат функционал обнаружения хостов и сканирования портов.
После обнаружения доступного сетевого сервиса обычно осуществляется его зондирование для сбора максимально возможного объема информации. Используя такие методы, как «снятие отпечатков» или «захват баннеров», сканер собирает такие данные, как разработчик и номер версии программного обеспечения. Многие инфраструктурные сканеры также отправляют безопасные тестовые сообщения к определенным типам сервисов, чтобы получить более информативные ответы или непосредственно проверить наличие уязвимости. После получения «отпечатка» сервиса эти данные также сверяются с базой знаний по продуктам, в которых подтверждено наличие уязвимостей системы безопасности.
Хотя некоторые сетевые сканеры уязвимостей используют и более сложные методы и могут поддерживать проверки с предварительной аутентификацией, обычно их целью является ширина, а не глубина охвата. Например, такие сканеры преимущественно не способны осуществлять навигацию по веб-приложениям или выявлять уязвимости, требующие сложного взаимодействия со специализированными протоколами. Однако они вполне способны выявлять уязвимости, которые возникают из-за использования устаревшего программного обеспечения или слабых настроек шифрования на тех же портах.
Таким образом, сетевые сканеры уязвимостей являются отличным решением для мониторинга сетей с большим внешним периметром на предмет появления новых распространенных уязвимостей, которыми могут воспользоваться злоумышленники из интернета или внутренней корпоративной сети. Они также наиболее полезны для IТ-инфраструктур, состоящих преимущественно из готовых коммерческих решений и содержащих минимум специально разработанного программного обеспечения или не содержащих его вообще.
Сканеры веб-приложений
Сканеры веб-приложений специально разработаны для выявления уязвимостей в приложениях и веб-сервисах, доступных через протоколы HTTP/S.
Это достигается путем взаимодействия с приложениями почти так же, как это делает веб-браузер, однако с возможностью отправлять запросы с гораздо более высокой скоростью. Эти запросы формируются таким образом, чтобы инициировать от веб-сервера ответы, которые бы указывали на наличие уязвимости.
Обычно сканеры веб-приложений проверяют систему на наличие широкого спектра проблем безопасности, которые могут повлиять как на сам веб-сервер, так и на других пользователей приложения. Часто эти проверки согласовываются с такими публикациями, как OWASP Top 10 – периодически обновляемым списком наиболее критических рисков безопасности для веб-приложений. В отличие от сканеров сетевой инфраструктуры, сканеры веб-приложений предназначены для выявления уязвимостей в специально разработанных и часто очень сложных веб-приложениях.
Современные сканеры веб-приложений также могут поддерживать более продвинутые методы настройки. Это может охватывать возможность указывать страницу авторизации и учетные данные для целевого приложения, а также исключать определенные типы сканирований или страницы. Без этих функций сканер вряд ли сможет обеспечить надлежащее тестовое покрытие для более сложных веб-приложений. Кроме того, он может вызвать нежелательные побочные эффекты, такие как создание большого объема записей в базе данных из-за многократной отправки форм. В целом, чем точнее сканер настроен под целевое веб-приложение, тем более релевантными и полезными будут результаты его работы.
Сканеры безопасности веб-приложений являются оптимальным выбором для использования в комплексе с сетевыми сканерами уязвимостей. Они также идеально подходят для случаев, когда специально разработанные веб-приложения составляют большую часть внешнего сетевого периметра и, соответственно, являются основным источником риска для бизнеса или организации.
Сканеры нативного программного обеспечения
Эти решения для сканирования подобны своим аналогам для веб-приложений тем, что они предназначены для выявления распространенных недостатков в процессе разработки и развертывания кастомных приложений.
Однако, в отличие от сканеров веб-приложений, решения для сканирования нативного программного обеспечения предназначены для запуска во внутренней среде. Часто это происходит на том же хосте, где размещен оцениваемый программный продукт, или в среде с прямым доступом к его исходному коду. Это позволяет выполнять проверки, которые были бы невозможны путем простого взаимодействия с внешним веб-приложением с ограниченным сетевым доступом.
Сравнительный анализ: Инфраструктурные сканеры vs Сканеры веб-приложений
| Тип сканирования уязвимостей | Связанные активы | Примеры выявленных проблем |
| Инфраструктура | – Компоненты сетевой инфраструктуры – Физические хосты – Виртуальные хосты – Устройства конечных пользователей – Облачные хосты или конечные точки | – Отсутствие обновлений ОС или программного обеспечения – Неподдерживаемые ОС или программное обеспечение – Использование стандартных или слабых паролей – Использование слабой криптографии или сервисов передачи данных в открытом виде – Незащищенность критических сервисов или конфиденциальной информации – Отсутствие мер по усилению безопасности – Чрезмерно широкие права доступа |
| Веб-приложения | – Конечные точки API – Веб-приложения – Домены | – Инъекции через вредоносный ввод данных – Недостатки механизмов аутентификации – Раскрытие конфиденциальных персональных или системных данных – Недостатки механизмов контроля доступа – Использование уязвимых сторонних компонентов – Использование слабой криптографии или нешифрованных каналов связи |
4. Выбор модели развертывания
Рынок решений и услуг по сканированию уязвимостей предлагает как традиционную модель локального развертывания (on-premises), так и все более популярную модель размещения на стороне поставщика. Целесообразно выбирать ту модель развертывания, которая лучше всего интегрируется с существующей инфраструктурой и соответствует ограничениям безопасности организации.
Локальные решения
При локальном развертывании клиент должен самостоятельно размещать продукт для сканирования на собственной инфраструктуре. Это может предусматривать, например, использование виртуальной машины или физического оборудования непосредственно в информационном центре.
Такой тип развертывания значительно облегчает сканирование участков сети, не имеющих внешнего подключения. Кроме того, в таких случаях данные хранятся локально, что обеспечивает полный контроль над местом хранения любой конфиденциальной информации об уязвимостях в системах.
Однако большая степень административного контроля имеет свою цену. Такие развертывания неизбежно требуют определенной начальной настройки и постоянного обслуживания для того, чтобы системы оставались актуальными и могли выявлять новейшие уязвимости.
Кроме того, локальные решения не могут легко масштабироваться для удовлетворения пиковых нагрузок, которые могут возникать во время одновременного сканирования крупных частей IТ-инфраструктуры. Это может привести к затратам на содержание избыточных вычислительных ресурсов без уверенности в том, что они когда-либо понадобятся. Эта проблема касается не только сканеров уязвимостей, но и локального размещения инфраструктуры в целом.
Учитывая это, локальные решения целесообразно использовать для сканирования систем, которые труднодоступны из интернета, или в случаях, когда организация уже имеет необходимые ресурсы для локального размещения инфраструктуры.
Решения, размещенные у поставщика
Сегодня многие решения также предлагаются как услуга, при которой программное обеспечение для сканирования размещается удаленно и находится под контролем и управлением поставщика.
Такая модель часто называется «Программное обеспечение как услуга» (Software as a Service, или SaaS). Это может быть экономически выгодным способом устранения многих недостатков локальных решений, однако она также имеет собственные минусы.
Поскольку это сервис, размещаемый извне, сканеры SaaS не могут легко получить доступ к внутренним сетям, расположенным за межсетевыми экранами (брандмауэрами) и маршрутизаторами. Эту проблему можно решить путем установки агентов во внутренних сетях для создания исходящих соединений с серверами поставщика с целью получения инструкций. Если такой вариант невозможен, межсетевые экраны можно перенастроить для разрешения входящих соединений от известных сканеров.
Это неизбежно потребует от сетевых администраторов определенной начальной настройки, которая может быть как простой, так и сложной, в зависимости от общей архитектуры IТ-инфраструктуры.
Любые изменения, внесенные в сеть для обеспечения возможности такого сканирования, повышают уровень риска для организации из-за необходимости предоставления определенного уровня доверия поставщику услуг. Это должно быть четко задокументировано и учтено в модели безопасности.
Преимущества SaaS
Несмотря на указанные выше факторы, сканеры SaaS имеют много преимуществ по сравнению с локальными решениями. Отсутствие установленного программного обеспечения или физического оборудования устраняет потребность в выполнении задач по техническому обслуживанию, таких как установка исправлений или обновление внутренней базы знаний по уязвимостям. Кроме того, решения SaaS обычно могут масштабироваться в соответствии с потребностями без затрат на постоянное содержание неиспользуемых вычислительных ресурсов.
В конечном итоге, хранение результатов сканирования уязвимостей на стороне поставщика упрощает задачи по применению защитных мер. Это гарантирует, что такая информация будет оставаться конфиденциальной и в то же время доступной для тех, кому она необходима (при условии готовности доверять средствам контроля самого поставщика).
Использовать решения, размещенные у поставщика, целесообразно в том случае, если технические сложности и риски безопасности, связанные с предоставлением внешнего доступа к IТ-инфраструктуре и хранением информации об уязвимостях организации на стороне провайдера, можно легко преодолеть. Однако такое решение не подходит для оценки изолированных сетей или тех, которые содержат чрезвычайно конфиденциальную информацию.
5. Определение активов для сканирования и времени его проведения
Хотя более широкий охват IТ-инфраструктуры обеспечивает более полное понимание общих рисков организации, сканирование абсолютно всех элементов может быть непрактичным или финансово нецелесообразным. В таких случаях приоритет следует предоставлять активам, которые доступны из интернета, поддерживают критически важные для бизнеса сервисы или содержат наиболее конфиденциальные данные (например, серверы баз данных).
Важно вести учет активов, которые исключаются из сканирования на наличие уязвимостей. Это необходимо для того, чтобы связанные с ними риски можно было должным образом учесть в модели безопасности организации.
Экстраполяция результатов тестирования
В случаях, когда несколько хостов развернуто из «эталонного образа» (golden image), который гарантирует одинаковую конфигурацию (как это часто бывает при стандартном развертывании рабочих станций), и никаких дальнейших изменений не вносилось, вполне нормально просканировать только один хост, созданный из этого образа, и экстраполировать полученные результаты на другие хосты.
Хотя вероятность того, что сканеры уязвимостей повлияют на доступность сервисов или вызовут другие сбои, очень низка, целесообразно сначала проводить сканирование тестовых экземпляров серверов, на которых размещены критически важные для бизнеса сервисы. Это даст результаты, которые можно применить к рабочей среде, только при условии, что конфигурации обеих сред идентичны. Дальнейшее сканирование рабочих систем все равно необходимо проводить в случаях, когда эти конфигурации отличаются, а также после подтверждения того, что сканирование не повлияло на доступность нерабочих экземпляров.
При отсутствии тестовой среды и наличии опасений относительно нестабильности определенных критически важных хостов, разрешается временно исключить их из потенциально опасных сканирований, обязательно зафиксировав это в реестре рисков. Делать это следует с осторожностью и на как можно более короткий период, поскольку такие действия создают «слепые зоны» на поверхности атаки организации.
Значительно лучшим решением в таких обстоятельствах является устранение первопричины нестабильности, чтобы хосты можно было снова сканировать без опасений вызвать перебои в работе сервисов. На самом деле нестабильность работы стоит рассматривать как отдельную уязвимость, требующую немедленного устранения.
Регулярное сканирование
Сканирование уязвимостей инфраструктуры следует проводить на регулярной основе (минимум раз в месяц) или немедленно после внесения изменений для устранения критической проблемы.
Сканеры приложений необходимо запускать каждый раз, когда в целевое приложение вносятся изменения, например, при установке новой версии или после фиксации изменений в исходном коде специально разработанного программного обеспечения. По возможности, решения для сканирования приложений следует интегрировать в процесс разработки программного обеспечения как часть конвейера безопасной сборки и развертывания.
Дополнительные критерии выбора
Существует множество других аспектов, которые следует учитывать при определении соответствия сервисов сканирования уязвимостей специфическим потребностям. Хотя часто сложно дать точное определение тому, что является «хорошим» или «плохим» в каждом конкретном случае, ниже приведен перечень основных критериев. Рекомендуется запрашивать эту информацию у потенциальных поставщиков для дальнейшего использования в процессе внутреннего оценивания:
Оперативность реагирования:
Способно ли решение обнаружить новую уязвимость в пределах приемлемого периода времени после ее публичного раскрытия? Для критических проблем это время не должно превышать нескольких дней.
Охват:
Покрывает ли сканер те категории уязвимостей, которые релевантны и критически важны для инфраструктуры? Например, в случае сканеров веб-приложений, выявляются ли все проблемы из перечня OWASP Top 10?
Поддержка аутентификации:
Поддерживает ли сканер проверки с аутентификацией? Например, способен ли он авторизоваться на хостах Windows для выполнения проверок, которые иначе недоступны? Поддерживается ли только локальная аутентификация с помощью агента, а также удаленная аутентификация? Предусмотрены ли защитные механизмы для предотвращения блокировки учетных записей?
Точность:
Часто ли сканер генерирует ложноположительные результаты или ложноотрицательные? Например, идентифицирует ли он некорректно старые версии программных продуктов, или утверждает ли, что исправления не были применены, хотя фактически они были установлены?
Надежность:
Доступен ли сканер постоянно для выполнения задач как по автоматическому расписанию, так и в ручном режиме по требованию?
Масштабируемость:
Сохраняет ли сканер высокую производительность во время периодов повышенной нагрузки, и базируется ли модель ценообразования на необходимой мощности в любой конкретный момент времени?
Возможности отчетности:
Можно ли адаптировать отчеты в соответствии со специфическими потребностями организации? Обеспечивают ли функции отчетности надлежащую информацию и метрики для поддержки команд по кибербезопасности и системному администрированию?
Поддержка других направлений VMP:
Легко ли решение интегрируется с существующими продуктами или процессами? Как альтернатива, предоставляет ли решение дополнительные функции, кроме базового обнаружения уязвимостей, которые дополнили бы текущую программу управления уязвимостями (например, встроенная система отслеживания задач/проблем)?
Интеграция с другими компонентами ОС:
Способно ли решение обеспечить дополнительную ценность за счет использования уже установленного программного обеспечения на целевых хостах? Например, интегрируется ли оно с Microsoft System Center на хостах Windows для обеспечения интеллектуальных возможностей управления исправлениями?
Поддержка различных типов активов:
Например, поддерживает ли решение сканирование виртуальных машин, контейнеров или специализированных серверов баз данных?
Интеграция с облачными средами:
Способно ли решение взаимодействовать с популярными облачными провайдерами для автоматического обнаружения и сканирования дополнительных активов, размещенных в этих средах?
Безопасность работы:
Гарантирует ли поставщик, что активность сканирования не нарушит доступность целевых сервисов? Если нет, можно ли настроить решение таким образом, чтобы исключить наиболее опасные типы проверок?
