A10:Insufficient-logging-monitoring OWASP TOP 10
В продолжение о тестировании безопасности проектов статейка на основе OWASP TOP 10.
Ну что?! Добьем уже нашу 10-у критических уязвимостей... Закроем этот топик "Insufficient Logging&Monitoring" этой недоработочкой...
При недостаточном мониторинге и покрытии логами вашей системы, веб приложения, возникает угроза со стороны слабых мест. И ваша задача состоит в том, чтоб обнаружить эти места, до того как их взломает злоумышленник. Злоумышленники, при выполнении своих злодеяний, полагаются на отсутствие контроля и своевременного реагирования на ихнии атаки. Так вот, к чему это я.... без нормального журнала мониторинга трудно или невозможно идентифицировать и инциденты, да и чтоб найти и устранить дыроньки на проблемных местах, тоже нужны нормальные логи с нашего приложения.
Классическая лог-архитектура генерирует как логи по безопасности, так и оперативные логи. Она должна уметь анализировать, сохранять и контролировать их. Это важно не только для борьбы с угрозами, возникающими из-за недостаточного ведения логов и мониторинга, но и для соответствия нормативным требованиям. Определение нарушения часто занимают большую часть времени у компаний, а в некоторых случаях и до 190 дней, и могут стоить предприятиям миллионы долларов на потери репутации.
Уязвимости в логах по безопасности и по работе системы
Оба этих типов отличаются друг от друга. В рабочие логи будут входить рутинные системные события, такие как получения и отдача реквестов от клиента к серверу или передачи данных в сетях. Они также могут еще получать логи от соответствующего программного обеспечения. А вот логи по безопасности включают в себя брандмауэры, маршрутизаторы, а также устройства служб безопасности хоста или сети.
Рабочие логи необходимы для того, чтобы оттачивать сомнительные действия, которые могут привести к атаке на критически важные данные. Однако логи по безопасности часто считаются дополнительными, в зависимости от того, что требуется конкретной компании, для расследования уязвимости или угрозы. В любом случае, оба типа журналов имеют неоценимое значение для выявления и устранения недостаточного логирования и мониторинга.
Основные уязвимости включают в себя:
- Незафиксированные события, такие как ошибочные учетные данные. Допустим, при авторизации выполнения брутфорса.
- Локально хранящиеся логи без облачного резервного копирования. Допустим, навернулся у вас сервак, а копии нету.
- Неправильные конфигурации в брандмауэрах и системах маршрутизации. Допустим пакеты данных летят не туда, а вы не сможете определить куда же они летят.
- Оповещения и последующие ответы, которые не обрабатываются эффективно. К примеру, вам приходит алекрт так часто и имеет не информативный след, что вы просто напросто забиваете на его приходы и просто мютите его.
- Оповещения о вредоносной активности не обнаруживаются в режиме реального времени. К примеру вас ддосят, а алерт про эту атаку придет через час или более позднее время.
По-этому тестерам и аудиторам на проникновения нужно периодически проверять компьютерные системы, приложения, связанные серверы и сети. Все действия тестировщиков должны быть записаны в достаточной степени, чтобы понять, какой ущерб может нанести данная слабость логирования. Недостатки в мониторинге - это и есть уязвимость, которую необходимо устранить, как только они будут выявлены. Придерживайтесь лучших практик вашей компании, если ваша компания их установила. Профилактика является ключевым звеном в предотвращении этой дыроньки.
Как защитится:
- Убедитесь, что все ошибки входа в систему, проверки входных данных на стороне сервера могут регистрироваться с достаточным контекстом для выявления подозрительных или злонамеренных учетных записей. А также, чтоб они могли храниться в течение достаточного времени для проведения отложенного судебного анализа.
- Убедитесь, что журналы создаются в формате, который можно легко использовать для решений централизованного управления логами.
- Убедитесь, что транзакции с высокой стоимостью имеют контрольный журнал с элементами управления целостностью, чтобы предотвратить подделку или удаление.
- Обеспечить эффективный мониторинг и оповещение таким образом, чтобы подозрительные действия обнаруживались и своевременно реагировались.
- Разработать или принять план реагирования на инциденты и восстановления, такой как NIST 800-61 rev 2 или более поздний.
И ПОМНИТЕ ВСЕ ПОКАЗАННОЕ ВЫШЕ, СДЕЛАНО В ЦЕЛЯХ ОБУЧЕНИЯ!!!
МОЖНО ПРИМЕНЯТЬ ТОЛЬКО НА СВОИХ ПРОЕКТАХ, ПОСЛЕ РАЗРЕШЕНИЯ
Хотите узнать больше о различных уязвимостях и инструментах для поиски этих же уязвимостей, чтоб сделать ваш проект безопасным, для ваших пользователей?
Мы организовываем тренинги по OWASP TOP 10.
Буду рад вас видеть на тренинге!
Программа тут
Ведение логов и мониторинга передового опыта
Если вы не обязываете вашу компанию собирать, хранить, поддерживать и отслеживать действия, то вы открываете себя для дорогостоящих нарушений в безопасности, которые вы не можете легко отследить. Журналы аудита предоставляют вашему ИТ-персоналу инструменты для идентификации и расследования взломов.
В большинстве штатов и территорий США приняты даже законы об уведомлении в нарушениях безопасности. Вот несколько правил, которые вы, возможно, должны соблюдать:
- Федеральный закон об управлении информационной безопасностью для федеральных систем агентств
- Закон Грэмма-Лича-Блейли для финансовых учреждений
- Закон Сарбейнса-Оксли 2002 года для финансовых и бухгалтерских целей
- Закон о мобильности и подотчетности медицинского страхования 1996 года (HIPAA) для здравоохранения
- Требование 10 стандарта безопасности данных индустрии платежных карт (PCI-DSS) для организаций, хранящих, обрабатывающих и передающих данные кредитных карт
Цели контроля для информационных и смежных технологий содержат больше информации, которая поможет вам в отношении лучших практик и растущих требований регулирующих органов.
Реализовать жизнеспособные политик по сбору логов
С нормальными логами вы можете минимизировать уязвимость A10, устанавливая возможные политики и процедуры, которые обеспечивают согласованность и соответствие всей инфраструктуре вашей компании.
Что нужно сделать:
- снизить риск взлома, установив четкие логи
- установить цели для регистрации событий с подозрительной активностью
- установить внутреннюю стандартизацию, распространив даже на тех, кто управляет этими процедурами
- защитить конфиденциальные и критически важные данные в логах, дабы не светить в открытом доступе данными своих пользователей
Выполнив эти задачи, вы придете к успеху...
Предотвращение недостаточной регистрации логов и мониторинга
Понятное дело, что постоянно самому высматривать логи это тяжко и не каждый захочет это делать вручную, так сказать. Информации в этих логах могут быть нескончаемыми. По-этому, чтоб упростить это дело, существует множество коммерческих и открытых фреймворков для управления логами, которые могут автоматизировать процесс мониторинга.
Тестеры и аудиторы на проникновение, как правило, ресурсоемки и дороги, но иногда необходимы. Должно быть новое мышление, которое взглянет на ваш проект с другой стороны. Они вам помогут найти, почему ваша компания уязвима и как предотвратить атаки, прежде чем они начнутся со стороны злоумышленников. А также это не только обеспечит жизнеспособность вашей компании, но и будет соответствовать безопасности вашего бренда.
Примеры атак:
1) Злоумышленник использует подбор данных логина и пароля на странице авторизации, как вы догадались, вон выполняет большое кол-во запросов к серверу дабы подобрать нужные креды. Если у нас был бы мониторинг то мы бы могли определить банально с какого адреса ломятся, чтоб что-то сделать с ним.
2) У крупной компании, была внутренняя песочница для анализа вредоносных программ, анализирующая вложения. Программное обеспечение «песочницы» обнаружило потенциально нежелательное программное обеспечение. Если бы у вас присутствовал функционал шлющий предупреждения, что какое-то из ПО начало сжирать все ресурсы, то вы бы заблаговременно смогли бы убить процесс этой проги. В итоги компания пострадала, все данные находящееся в песочнице были благополучно спижеными злоумышленниками.
