К профилю facebook
К профилю linkedin
gallery/gallery-1
A10:Insufficient-logging-monitoring OWASP TOP 10
Вернуться назад

В продолжение о тестировании безопасности проектов статейка на основе OWASP TOP 10

gallery/выделение_009

Ну что?! Добьем уже нашу 10-у критических уязвимостей... Закроем этот топик "Insufficient Logging&Monitoring" этой недоработочкой...

 

При недостаточном мониторинге и покрытии логами вашей системы, веб приложения, возникает угроза со стороны слабых мест. И ваша задача состоит в том, чтоб обнаружить эти места, до того как их взломает злоумышленник. Злоумышленники, при выполнении своих злодеяний, полагаются на отсутствие контроля и своевременного реагирования на ихнии атаки. Так вот, к чему это я.... без нормального журнала мониторинга трудно или невозможно идентифицировать и инциденты, да и чтоб найти  и устранить дыроньки на проблемных местах, тоже нужны нормальные логи с нашего приложения. 

 

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

Уязвимости в логах по безопасности и по работе системы

Оба этих типов отличаются друг от друга. В рабочие логи будут входить рутинные системные события, такие как получения и отдача реквестов от клиента к серверу или передачи данных в сетях. Они также могут еще получать логи от соответствующего программного обеспечения. А вот логи по безопасности включают в себя брандмауэры, маршрутизаторы, а также устройства служб безопасности хоста или сети.

 

Рабочие логи необходимы для того, чтобы оттачивать сомнительные действия, которые могут привести к атаке на критически важные данные. Однако логи по безопасности часто считаются дополнительными, в зависимости от того, что требуется конкретной компании, для расследования уязвимости или угрозы. В любом случае, оба типа журналов имеют неоценимое значение для выявления и устранения недостаточного логирования и мониторинга.

 

Основные уязвимости включают в себя:

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

 

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

 

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

 

- Оповещения и последующие ответы, которые не обрабатываются эффективно. К примеру, вам приходит алекрт так часто и имеет не информативный след, что вы просто напросто забиваете на его приходы и просто мютите его.

 

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

 

По-этому тестерам и аудиторам на проникновения нужно периодически проверять компьютерные системы, приложения, связанные серверы и сети. Все действия тестировщиков должны быть записаны в достаточной степени, чтобы понять, какой ущерб может нанести данная слабость логирования. Недостатки в мониторинге - это и есть уязвимость, которую необходимо устранить, как только они будут выявлены. Придерживайтесь лучших практик вашей компании, если ваша компания их установила. Профилактика является ключевым звеном в предотвращении этой дыроньки. 

 

Как защитится:

 

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

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

- Убедитесь, что транзакции с высокой стоимостью имеют контрольный журнал с элементами управления целостностью, чтобы предотвратить подделку или удаление.

- Обеспечить эффективный мониторинг и оповещение таким образом, чтобы подозрительные действия обнаруживались и своевременно реагировались.

- Разработать или принять план реагирования на инциденты и восстановления, такой как  NIST 800-61 rev 2  или более поздний.

И ПОМНИТЕ ВСЕ ПОКАЗАННОЕ ВЫШЕ, СДЕЛАНО В ЦЕЛЯХ ОБУЧЕНИЯ!!!

МОЖНО ПРИМЕНЯТЬ ТОЛЬКО НА СВОИХ ПРОЕКТАХ, ПОСЛЕ РАЗРЕШЕНИЯ

Хотите узнать больше о различных уязвимостях и инструментах для поиски этих же уязвимостей, чтоб сделать ваш проект безопасным, для ваших пользователей? 

Мы организовываем тренинги по OWASP TOP 10. 

Буду рад вас видеть на тренинге!

 

Программа тут

 

 

gallery/logo3
gallery/выделение_034

Ведение логов и мониторинга передового опыта

Если вы не обязываете вашу компанию собирать, хранить, поддерживать и отслеживать действия, то вы открываете себя для дорогостоящих нарушений в безопасности, которые вы не можете легко отследить. Журналы аудита предоставляют вашему ИТ-персоналу инструменты для идентификации и расследования взломов.

 

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

 

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

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

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

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

- Требование 10 стандарта безопасности данных индустрии платежных карт (PCI-DSS) для организаций, хранящих, обрабатывающих и передающих данные кредитных карт

 

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

gallery/standards
gallery/iot_dev

Реализовать жизнеспособные политик по сбору логов

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

 

Что нужно сделать:

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

- установить цели для регистрации событий с подозрительной активностью

- установить внутреннюю стандартизацию, распространив даже на тех, кто управляет этими процедурами

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

 

Выполнив эти задачи, вы придете к успеху...

gallery/244-4-h
gallery/выделение_035

Предотвращение  недостаточной  регистрации логов и мониторинга

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

 

Тестеры и аудиторы на проникновение, как правило, ресурсоемки и дороги, но иногда необходимы. Должно быть новое мышление, которое взглянет на ваш проект с другой стороны. Они вам помогут найти, почему ваша компания уязвима и как предотвратить атаки, прежде чем они начнутся со стороны злоумышленников. А также это не только обеспечит жизнеспособность вашей компании, но и будет соответствовать безопасности вашего бренда.

gallery/выделение_038

Примеры атак:

 

1) Злоумышленник использует подбор данных логина и пароля на странице авторизации, как вы догадались, вон выполняет большое кол-во запросов к серверу дабы подобрать нужные креды. Если у нас был бы мониторинг то мы бы могли определить банально с какого адреса ломятся, чтоб что-то сделать с ним.

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

gallery/выделение_039