A9: Insufficient logging monitoring

Протягом тестування безпеки проектів статейка на основі OWASP TOP 10

Запобігання недостатній реєстрації логів та моніторингу

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

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

Приклади атак:

1) Зловмисник використовує підбір даних логіну і пароля на сторінці авторизації, як ви здогадалися, він виконує велику кількість запитів до сервера щоб підібрати необхідні креди. Якщо в нас був би моніторинг, то ми б могли визначити банально з якої адреси ломляться, щоб щось зробити з ним.

Ну що?! Доб'ємо вже нашу 9 критичних уразливостей... Закриємо цей топік "Insufficient Logging&Monitoring" цією недоробкою...

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

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

Уразливості в логах з безпеки та роботи системи

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

Робочі логи потрібні для того, щоб відточувати сумнівні дії, які можуть призвести до атаки на критично важливі дані. Проте логі безпеки часто вважаються додатковими, залежно від того, що потрібно конкретної компанії, для розслідування вразливості або загрози. У будь-якому випадку, обидва типи журналів мають неоціненне значення для виявлення та усунення недостатнього логування та моніторингу.

Основні вразливості включають:

- Незафіксовані події, такі як помилкові облікові дані. Допустимо, при авторизації виконання брутфорсу.

- Логи, що зберігаються, без хмарного резервного копіювання. Допустимо, навернувся у вас сервак, а копії немає.

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

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

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

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

Ведення логів та моніторингу передового досвіду

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

У більшості штатів і територій США ухвалено навіть закони про повідомлення у порушеннях безпеки. Ось кілька правил, яких ви, можливо, повинні дотримуватися:

- Федеральний закон про управління інформаційною безпекою для федеральних систем агенцій

- Закон Грема-Ліча-Блейлі для фінансових установ

- Закон Сарбейнса-Окслі 2002 року для фінансових та бухгалтерських цілей

- Закон про мобільність та підзвітність медичного страхування 1996 року (HIPAA) для охорони здоров'я

- Вимога 10 стандарту безпеки даних індустрії платіжних карток (PCI-DSS) для організацій, що зберігають, обробляють та передають дані кредитних карток

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

Реалізувати життєздатні політик зі збирання логів

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

Що потрібно зробити:

- знизити ризик злому, встановивши чіткі логи

- встановити цілі для реєстрації подій з підозрілою активністю

- встановити внутрішню стандартизацію, поширивши навіть тих, хто керує цими процедурами

- захистити конфіденційні та критично важливі дані в логах, щоб не світити у відкритому доступі даними своїх користувачів

Виконавши ці завдання, ви прийдете до успіху.

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

Як захиститься:

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

- Переконайтеся, що журнали створюються у форматі, який можна легко використовувати для централізованого управління логами.

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

- Забезпечити ефективний моніторинг та оповіщення таким чином, щоб підозрілі дії виявлялися та своєчасно реагувалися. - Розробити або прийняти план реагування на інциденти та відновлення, такий як NIST 800-61 rev 2 або пізніший.