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