Оцінка вразливості з посібника Kali Linux від OnWorks

Перейти до вмісту

11.2.1. Оцінка вразливості

A вразливість вважається слабкістю, яка може бути використана якимось чином для порушення конфіденційності, цілісності або доступності інформаційної системи. Під час оцінки вразливостей ваша мета полягає в тому, щоб створити простий перелік виявлених уразливостей у цільове середовище. Ця концепція цільового середовища надзвичайно важлива. Ви повинні бути впевнені, що залишаєтеся в межах цільової мережі вашого клієнта та необхідних цілей. Вихід за рамки оцінки може призвести до переривання обслуговування, зловживання довірою з клієнтом або судового позову проти вас і вашого роботодавця.

Завдяки своїй відносній простоті тест на вразливість часто виконується в більш зрілих середовищах на регулярній основі як частина демонстрації їх належної обачності. У більшості випадків це автоматизований інструмент, як-от аналіз уразливостей7 і веб-додатки8 категорії сайту Kali Tools і меню настільних програм Kali, використовується для виявлення живих систем у цільовому середовищі, ідентифікації служб прослуховування та їх перерахування, щоб виявити якомога більше інформації, наприклад, програмне забезпечення сервера, версію, платформу тощо. .

Потім ця інформація перевіряється на наявність відомих ознак потенційних проблем або вразливостей. Ці підписи складаються з комбінацій точок даних, які призначені для представлення відомих проблем. Використовується кілька точок даних, тому що чим більше точок даних ви використовуєте, тим точніше буде ідентифікація. Існує дуже велика кількість потенційних точок даних, включаючи, але не обмежуючись ними:

• Версія операційної системи: нерідко програмне забезпечення є вразливим в одній версії операційної системи, але не в іншій. Через це сканер намагатиметься якомога точніше визначити, яка версія операційної системи містить цільову програму.

• Рівень виправлення: багато разів будуть випущені виправлення для операційної системи, які не збільшують інформацію про версію, але все одно змінюють спосіб реагування на вразливість або навіть повністю усувають уразливість.

• Архітектура процесора: багато програмних програм доступні для багатьох архітектур процесорів, таких як Intel x86, Intel x64, кілька версій ARM, UltraSPARC тощо.

5https://en.wikipedia.org/wiki/Executable_space_protection#Windows 6https://en.wikipedia.org/wiki/Address_space_layout_randomization 7http://tools.kali.org/category/vulnerability-analysis 8http://tools.kali.org/category/web-applications‌‌‌

У деяких випадках уразливість буде існувати лише в певній архітектурі, тому знання цієї інформації може бути критичним для точного підпису.

• Версія програмного забезпечення. Версія цільового програмного забезпечення є одним із основних елементів, які необхідно зафіксувати для виявлення вразливості.

Ці та багато інших точок даних будуть використані для створення підпису в рамках сканування уразливостей. Як і очікувалося, чим більше точок даних збігається, тим точнішим буде підпис. Коли ви маєте справу зі збігами підписів, ви можете отримати кілька різних потенційних результатів:

• Справжній позитив: підпис збігається, і він фіксує справжню вразливість. За цими результатами вам потрібно буде ознайомитися та виправити, оскільки зловмисники можуть скористатися ними, щоб нашкодити вашій організації (або клієнту).

• Хибнопозитивний: підпис збігається; однак виявлена проблема не є справжньою вразливістю. В оцінці це часто вважається шумом і може бути досить неприємним. Ви ніколи не захочете відкидати справжній позитив як хибнопозитивний без більш детальної перевірки.

• Справжній мінус: підпис не збігається і немає вразливості. Це ідеальний сценарій, який підтверджує відсутність уразливості на цілі.

• Помилковий негатив: підпис не збігається, але є наявна вразливість. Яким би поганим не був хибнопозитивний, хибнонегативний набагато гірший. У цьому випадку проблема існує, але сканер її не виявив, тому ви не маєте жодних ознак її існування.

Як ви можете собі уявити, точність підписів надзвичайно важлива для точних результатів. Чим більше надано даних, тим більше шансів отримати точні результати автоматичного сканування на основі підпису, тому аутентифіковані сканування часто настільки популярні.

При автентифікованому скануванні програмне забезпечення для сканування використовуватиме надані облікові дані для автентифікації цільової особи. Це забезпечує більш глибокий рівень видимості цілі, ніж це було б можливо. Наприклад, під час звичайного сканування ви можете виявити лише інформацію про систему, яку можна отримати від служб прослуховування та функціональних можливостей, які вони надають. Іноді це може бути досить багато інформації, але вона не може конкурувати з рівнем і глибиною даних, які будуть отримані, якщо ви автентифікуєтеся в системі та всебічно переглядаєте все встановлене програмне забезпечення, застосовані виправлення, запущені процеси тощо. . Ця широта даних корисна для виявлення вразливостей, які в іншому випадку могли б не бути виявлені.

Добре проведена оцінка вразливості представляє моментальний знімок потенційних проблем в організації та надає показники для вимірювання змін у часі. Це досить легка оцінка, але навіть багато організацій регулярно виконуватимуть автоматичне сканування уразливостей у неробочий час, щоб уникнути потенційних проблем протягом дня, коли доступність послуг і пропускна здатність є найбільш критичними.

Як згадувалося раніше, сканування уразливостей має перевірити багато різних точок даних, щоб отримати точний результат. Усі ці різні перевірки можуть створювати навантаження на цільову систему, а також споживати пропускну здатність. На жаль, важко точно визначити, скільки ресурсів буде витрачено на ціль, оскільки це залежить від кількості відкритих сервісів і типів

чеки, які будуть пов’язані з цими послугами. Це вартість виконання сканування; він буде займати системні ресурси. Під час використання цих інструментів важливо мати загальне уявлення про ресурси, які будуть споживані, і про те, яке навантаження може витримати цільова система.

Сканування потоків Більшість сканерів уразливостей мають опцію налаштування потоків за сканування, що дорівнює кількості одночасних перевірок, які відбуваються за один раз. Збільшення цієї кількості матиме прямий вплив на навантаження на платформу оцінки, а також на мережі та цілі, з якими ви взаємодієте. Це важливо пам’ятати під час використання цих сканерів. Спокуса збільшити кількість потоків, щоб швидше завершити сканування, але пам’ятайте про значне збільшення навантаження, пов’язане з цим.

Коли сканування уразливостей закінчується, виявлені проблеми зазвичай пов’язуються з промисловими стандартними ідентифікаторами, такими як номер CVE9, EDB-ID10, а також рекомендації постачальника. Ця інформація разом із оцінкою вразливостей CVSS11, використовується для визначення рейтингу ризику. Поряд з хибнонегативними (і хибнопозитивними) ці довільні рейтинги ризику є поширеними проблемами, які необхідно враховувати під час аналізу результатів сканування.

Оскільки автоматизовані інструменти використовують базу даних сигнатур для виявлення вразливостей, будь-яке невелике відхилення від відомого підпису може змінити результат, а також дійсність сприйнятої вразливості. Помилковий позитивний сигнал неправильно позначає вразливість, якої не існує, тоді як помилковий негатив фактично не бачить уразливості й не повідомляє про неї. Через це часто кажуть, що сканер настільки хороший, як і його база правил підпису. З цієї причини багато постачальників надають кілька наборів підписів: один, який може бути безкоштовним для домашніх користувачів, і інший досить дорогий набір, який є більш комплексним, який зазвичай продається корпоративним клієнтам.

Іншою проблемою, з якою часто стикаються сканування уразливостей, є дійсність запропонованих рейтингів ризику. Ці рейтинги ризику визначаються на загальній основі, враховуючи багато різних факторів, таких як рівень привілеїв, тип програмного забезпечення та попередня чи післяавтентифікація. Залежно від вашого середовища ці рейтинги можуть бути застосовними або не застосовними, тому їх не слід приймати наосліп. Тільки ті, хто добре розбирається в системах і вразливостях, можуть належним чином підтвердити рейтинги ризику.

Хоча не існує універсальної угоди про рейтинги ризику, спеціальна публікація NIST 800-3012 рекомендований як базовий рівень для оцінки рейтингів ризику та їх точності у вашому середовищі. NIST SP 800-30 визначає справжній ризик виявленої вразливості як поєднання ймовірності виникнення та потенційного впливу.

9https://cve.mitre.org 10https://www.exploit-db.com/about/ 11 https://www.first.org/cvss‌‌‌

12http://csrc.nist.gov/publications/PubsSPs.html#800-30