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