5 запитань, які ви маєте поставити своєму провайдеру вебзахисту

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

Ці запитання є найбільш доречними, якщо ваша організація вже використовує хмарну платформу для забезпечення веббезпеки частково або в цілому (тобто для очищення трафіку HTTP/S). Якщо ж ваше рішення веббезпеки — це апаратний пристрій, тоді у вас є додаткові вразливості, про які варто турбуватися.

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

Інші проблеми з пристроями стосуються підтримки їхньої актуальності (коли з’являються нові вебзагрози, треба випустити та встановити оновлення, що часто відбувається не відразу), масштабованості тощо.

Маючи це на увазі, перейдемо до запитань.

1. Як ви ізолюєте мої ресурси?

Модель оренди для рішення веббезпеки має досить сильний вплив на те, наскільки ефективно воно може ізолювати вебактиви кожного клієнта. Більшість хмарних рішень веббезпеки розгортаються на спільних мультиклієнтських обчислювальних ресурсах і сховищах (у деяких випадках їхні клієнти можуть навіть використовувати той самий SSL-сертифікат.) Ці домовленості з багатьма клієнтами створюють низку різних уразливостей.

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

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

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

Щоб уникнути всього цього, ваша організація має розгорнути платформу веббезпеки в середовищі з одним клієнтом.

2. Наскільки глибокий ваш аналіз?

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

1. Перевірку заголовків і параметрів
2. Підтримку HTTP GET
3. Підписання файлів cookie
4. Підтримку HTTP POST
5. Підтримку корисного навантаження JSON

Рішення веббезпеки відрізняються глибиною аналізу. Багато рішень пропонують лише перші два типи аналізу. Доволі невелика кількість рішень також передбачає підпис файлів cookie та підтримку HTTP POST.

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

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

3. Наскільки ефективним є ваше виявлення ботів?

Традиційно ворожих ботів ідентифікували за допомогою кількох різних підходів. До них належать:

• Розпізнавання підпису: визначення шаблонів у вхідних запитах, які свідчать про те, що ініціатором є бот.
• Обмеження швидкості: використання порогових значень швидкості для обмеження трафіку з одного джерела.
• Чорний список: відхилення вхідних запитів від IP-адрес, що відомі як ворожі.
• JavaScript-ін’єкція (JavaScript injection) та інші тести, як от робота з файлами cookie, щоб виявити відсутність нормального середовища веббраузера.
• Проблеми CAPTCHA та reCAPTCHA.

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

На жаль, то єдині методи, які використовуються в більшості рішень веббезпеки. І це погана новина, оскільки суб’єкти кіберзагроз адаптувалися. Новіші покоління ботів можуть уникнути виявлення цими традиційними методами:

• Метод сигнатурного розпізнавання обходять шляхом спуфінга рядків агента користувача та інших оманливих дій, тому бот виглядає як легітимний користувач.
• Обмеження швидкості можна уникнути шляхом ротації IP-адрес та/або підтриманням швидкості запитів на «розумному» рівні.
• Ротація IP-адрес також дає змогу уникнути внесення в чорний список.
• Деякі автономні браузери (тобто веббраузери, які запускаються програмно без графічного інтерфейсу користувача) тепер можуть маскуватися під «справжні» веббраузери: вони здатні обробляти файли cookie, виконувати JavaScript тощо.
• Дослідники знайшли спосіб автоматично вирішувати завдання CAPTCHA та reCAPTCHA. Навіть останню версію reCAPTCHA можна вирішити автоматизованими методами у 97% випадків.

Для точного виявлення ботів останнього покоління рішення веббезпеки має використовувати такі методи, як машинне навчання та UEBA (User and Entity Behavioral Analytics – Аналіз Поведінки Користувачів і Суб’єктів), щоб створювати та застосовувати профілі поведінки законних користувачів. Багато рішень ще не роблять цього.

№4: Як ви захищаєте мої API?

Виявлення та блокування зловживань API є життєво важливою та дедалі складнішою вимогою для надійної безпеки, тому що мобільні/нативні застосунки швидко поширюються як і API.

Завдяки API суб’єкти загрози мають більше можливостей і менший ризик виявлення. Деякі методи розпізнавання загроз у вебзастосунках (наприклад, аналіз середовища браузера) не застосовуються до API. Крім того, кожного разу, коли нові мобільні/нативні застосунки чи функції починають працювати, фронт атаки API розширюється.

Для веббезпеки, яка може відповідати швидким темпам розробки сучасних вебзастосунків і мобільних застосунків (особливо в середовищі DevOps/DevSecOps), рішення безпеки має забезпечувати різноманітні функції, включно з  надійним SDK на боці клієнта, автоматичним введенням схем і примусовим виконанням, запобіганням реверс-інженерії та детальною перевіркою корисного навантаження.

Якщо ваше рішення не надає всіх цих можливостей (а нині лише деякі рішення можуть таким похвалитися) це обмежує вашу здатність повністю захистити ваші API.

#5. Чи якісно ваше рішення безпеки поєднується з іншими?

Цілком імовірно, що у вас уже є ланцюжки інструментів безпеки, включно з рішеннями SIEM і SOC. У вас є постачальник CDN, який має власні вбудовані функції безпеки. Ваші команди DevOps мають добре налагоджену систему CI/CD*. Ви використовуєте ресурси одного або кількох публічних хмарних постачальників, у кожного з яких є власні набори служб безпеки.

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

- - - - - - - - - -
*CI/CD (Continuous Integration, Continuous Delivery, безперервна інтеграція та доставка) — технологія автоматизації тестування та доставки зацікавленим сторонам нових модулів проєкту, що розроблюється.

Бонусне запитання: навіть якщо рішення безпеки забезпечує деякі або всі пункти з перерахованого вище…

…чи воно надає все це як частину комплексного рішення?

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

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

Єдине комплексне рішення — Reblaze 

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

Консультації, демонстрація, придбання Reblaze

Якщо вас зацікавило потужне та надійне рішення для веббезпеки, якщо ви хочете захистити свій бізнес від потенційних кіберзагроз, напишіть запит на е-адресу: soft@megatrade.ua. Ми надамо вам додаткову інформацію, а також можливість ознайомитися з демонстраційною версією Reblaze — рішення з вебзахисту нового покоління. Мегатрейд є офіційним дистриб’ютором Reblaze в Україні.

Отримайте консультацію в Мегатрейд: soft@megatrade.ua

Reblaze Web Application Firewall

Відповіді на поширені запитання про Reblaze

Глобальна платіжна система Payoneer не відчуває кібератак завдяки рішенням безпеки хмарного постачальника Reblaze

Cloudflare VS Reblaze: порівняння платформ