4 липня ми проводили великий . Сьогодні ми публікуємо розшифровку виступу Андрія Новікова із Qualys. Він розповість, які етапи потрібно пройти, щоб побудувати робочий процес управління вразливістю. Спойлер: до сканування ми дістанемося тільки до середини шляху.
Крок № 1: Визначте рівень зрілості процесів керування вразливістю
На самому початку потрібно зрозуміти, на якому ступені знаходиться ваша організація з погляду зрілості процесів управління вразливістю. Тільки після цього ви зможете зрозуміти, куди вам рухатися і які кроки необхідно зробити. Перш ніж пускатися в сканування та інші заходи, організаціям потрібно провести внутрішню роботу та зрозуміти, як влаштовані ваші поточні процеси з погляду ІТ та інформаційної безпеки.
Спробуйте відповісти на базові запитання:
- чи є у вас процеси з інвентаризації та класифікації активів;
- наскільки регулярно сканується ІТ-інфраструктура і чи вся інфраструктура охоплена, чи всю картинку ви бачите;
- чи моніторяться ваші ІТ-ресурси;
- чи впроваджені у ваші процеси якісь KPI і як ви розумієте, що вони виконуються;
- чи документовано всі ці процеси.
Крок № 2: Забезпечте повне покриття інфраструктури
Ви не можете захистити те, про що ви не знаєте. Якщо ви не маєте повної картини того, з чого складається ваша ІТ-інфраструктура, ви не зможете її захищати. Сучасна інфраструктура складна і постійно змінюється кількісно та якісно.
Тепер ІТ-інфраструктура базується не тільки на стеку класичних технологій (робочі станції, сервери, віртуальні машини), але й на нових – контейнерах, мікросервісах. Служба інформаційної безпеки всіляко тікає від останніх, оскільки їй дуже складно працювати з ними за допомогою існуючих наборів інструментів, які складаються переважно зі сканерів. Проблема полягає в тому, що будь-який сканер не може покрити всю інфраструктуру. Щоб сканер достукався до будь-якого вузла в інфраструктурі, потрібно щоб збіглося відразу кілька факторів. Актив має бути всередині периметра організації на момент сканування. Сканери повинні мати доступ до активів, їх облікові записи, щоб зібрати повну інформацію.
За нашою статистикою, коли йдеться про середні чи великі організації, приблизно 15–20% інфраструктури не захоплюється сканером з тих чи інших причин: актив виїхав за межі периметра або взагалі ніколи не з'являється в офісі. Наприклад, ноутбук співробітника, який працює віддалено, але при цьому має доступ у корпоративну мережу, або актив знаходиться у зовнішніх хмарних сервісах типу Amazon. І сканер, швидше за все, нічого не знатиме про ці активи, оскільки вони поза зоною його видимості.
Щоб покрити всю інфраструктуру, потрібно використовувати не тільки сканери, а цілий набір сенсорів, включаючи технології пасивного прослуховування трафіку для виявлення нових пристроїв у вашій інфраструктурі, агентський метод збору даних, щоб отримувати інформацію, - дозволяє отримувати онлайн, без необхідності сканування, без виділення облікових даних.
Крок № 3: Виконайте категоризацію активів
Не всі активи однаково корисні. Визначити, які активи важливі, а які ні – ваше завдання. Жоден інструмент, той самий сканер, не зробить це за вас. В ідеалі ІБ, ІТ та бізнес разом аналізують інфраструктуру, щоб виділити бізнес-критичні системи. Вони визначають допустимі метрики за доступністю, цілісності, конфіденційності, RTO/RPO тощо.
Це допоможе визначити пріоритети у процесі управління вразливістю. Коли ваші спеціалісти будуть отримувати дані про вразливості, це буде не простирадло з тисячами вразливостей по всій інфраструктурі, а гранульована інформація з урахуванням критичності систем.
Крок №4: Проведіть оцінку інфраструктури
І ось лише на четвертому кроці ми приходимо до оцінки інфраструктури з погляду вразливостей. Рекомендуємо вам на цьому етапі приділяти увагу не тільки вразливості в ПЗ, але й помилок у конфігураціях, які також можуть бути вразливими. Тут ми рекомендуємо агентський метод збирання інформації. Сканери можна використовувати для оцінки безпеки периметра. Якщо ви використовуєте ресурси хмарних провайдерів, то звідти теж потрібно збирати інформацію щодо активів та конфігурацій. Окрему увагу приділіть аналізу вразливостей в інфраструктурах за допомогою Docker-контейнерів.
Крок № 5: Налаштуйте звітність
Це один із важливих елементів усередині процесу управління вразливістю.
Перший момент: ніхто не працюватиме з багатосторінковими звітами з безладним списком уразливостей та описом їх усунення. Потрібно насамперед спілкуватися з колегами та з'ясовувати, що має бути у звіті та як їм зручніше отримувати дані. Наприклад, якомусь адміністратору не потрібний докладний опис уразливості і потрібна лише інформація про патч та посилання на нього. Іншому фахівцю важливі лише уразливості, знайдені у мережній інфраструктурі.
Другий момент: під звітністю я розумію не лише паперові звіти. Це застарілий формат отримання інформації та статична історія. Людина отримує звіт і ніяк не може вплинути на те, як у цьому звіті будуть представлені дані. Щоб отримати звіт у потрібному вигляді, ІТ-фахівець повинен зв'язатися зі спеціалістом з ІБ та попросити його перебудувати звіт. Час іде, з'являються нові вразливості. Замість того, щоб перекидати звіти з відділу до відділу, фахівці обох напрямків повинні мати можливість спостерігати за даними онлайн та бачити ту саму картину. Тому у своїй платформі ми використовуємо динамічні звіти у вигляді дашбордів, що настроюються.
Крок № 6: Пріоритезуйте
Тут можна робити таке:
1. Створення репозиторію із золотими образами систем. Працюйте із золотими образами, перевіряйте їх на вразливості та коректність конфігурації на постійній основі. Зробити це можна за допомогою агентів, які автоматично повідомлятимуть про появу нового активу та надаватиму інформацію про його вразливості.
2. Сфокусуйте увагу на тих активах, які є критичними для бізнесу. Немає жодної організації у світі, яка може усунути уразливості за один прийом. Процес усунення вразливостей довгий і навіть моторошний.
3. Звуження поверхні атак. Очищайте інфраструктуру від непотрібного ПЗ, сервісів, закривайте непотрібні порти. У нас був нещодавно випадок із однією компанією, у якої на 40 тисячах пристроїв було знайдено близько 100 тисяч уразливостей, пов'язаних зі старою версією браузера Mozilla. Як потім з'ясувалося, Mozilla була впроваджена в золотий образ багато років тому, нею ніхто не користується, але вона є джерелом великої кількості вразливостей. Коли видалили браузер із комп'ютерів (він навіть стояв на якихось серверах), ці десятки тисяч вразливостей зникли.
4. Ранжуйте вразливості на базі даних розвідки (threat intelligence). Враховуйте не тільки критичність вразливості, а й наявність публічного експлойту, malware, патчу, зовнішнього доступу до системи з уразливістю. Оцінюйте вплив цієї вразливості на критичні бізнес-системи: чи може вона призвести до втрати даних, відмови в обслуговуванні та ін.
Крок № 7: Узгодьте KPI
Не скануйте, щоб сканувати. Якщо зі знайденими вразливістю нічого не відбувається, це сканування перетворюється на марну операцію. Щоб робота з уразливістю не перетворилася на формальність, продумайте, як ви оцінюватимете її результати. ІБ та ІТ повинні домовитися, яким чином буде побудовано роботу з усунення вразливостей, як часто проводитимуться сканування, встановлення патчів тощо.
На слайді ви побачите приклади можливих KPI. Є розширений список, який ми рекомендуємо своїм клієнтам. Якщо буде цікаво, звертайтеся, я цією інформацією поділюся з вами.
Крок №8: Автоматизуйте
Знову повернуся до сканування. Ми в Qualys вважаємо, що сканування - це не найважливіше, що може бути сьогодні в процесі управління вразливістю, і що в першу чергу потрібно його максимально автоматизувати, щоб він виконувався без участі фахівця з ІБ. Сьогодні є багато інструментів, які дозволяють це зробити. Достатньо, щоб у них був відкритий API та необхідна кількість конекторів.
Приклад, який я люблю наводити – це DevOps. Якщо ви впроваджуватимете туди сканер уразливості, то можна просто забути про DevOps. Зі старими технологіями, яким є класичний сканер, вас просто не пустять у ці процеси. Розробники не чекатимуть, поки ви проскануєте та віддасте їм багатосторінковий незручний звіт. Розробники чекають, що інформація про вразливість потраплятиме у вигляді інформації про баги в їхній системі складання коду. Безпека повинна бути безшовно вбудована в ці процеси, і вона повинна бути лише функцією, яка автоматично викликається системою, що використовується вашими розробниками.
Крок № 9: Фокусуйтеся на головному
Фокусуйтеся на тому, що приносить реальну користь вашій компанії. Сканування можуть бути автоматичними, звіти можуть надсилатися теж автоматично.
Сфокусуйтеся на покращенні процесів, щоб вони були більш гнучкими та зручними для всіх учасників. Фокусуйте на тому, щоб безпека була впроваджена у всі контракти з вашими контрагентами, які, наприклад, розробляють вам веб-додатки.
Якщо потрібна докладніша інформація про те, як побудувати в компанії процес управління вразливістю, звертайтеся до мене та моїх колег. Буду радий допомогти.
Джерело: habr.com