Обезопасить сеть нельзя обезопасить базы данных

Казалось бы, следует поставить запятую, а мы скажем — нет. В статье расскажем, как обезопасить сеть и данные с помощью продуктов «Гарда NDR» (Network Detection and Response) и «Гарда DBF» (Database Firewall). Преимущество использования двух продуктов: можно детектировать недопустимые события на самых ранних этапах, видеть всю цепочку и логику злоумышленника, что очень полезно для изучения уязвимостей нулевого дня.

Так, например, NDR может обнаружить атаку на ранних этапах, в то время как средствами DBF подобные атаки выявляются на этапах, относящихся к тактике сбора данных. Итак, рассмотрим более детально, как «Гарда DBF» и «Гарда NDR» работают сообща для блокировки нелигитимных запросов к базам данных.

Мы видим:

• какая политика сработала;

• какая тактика и техника политики соответствует тактике из классификатора MITRE ATT&CK;

• IP адрес атаки;

• детали SQL-транзакции, которую DBF посчитал потенциально опасной.

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

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

В данном случае нас интересует политика блокировки, так как мы планируем блокировать нелигитимные запросы, опираясь на список IP-адресов, который получаем из продукта «Гарда NDR».

С помощью этого списка происходит интеграция двух решений.

Также выставляем настройку для отправки уведомления по email, это благодаря ей мы получили сообщения о срабатывании политики на email.

Давайте посмотрим, что представляет из себя список блэк-лист, который мы получаем из «Гарда NDR», куда мы его загружаем, и где он отображается.

«Гарда DBF» отправляет запрос select в выделенную базу данных, в которой находится блэк-лист NDR.

Посмотрим, какие еще есть политики.

Следующая политика направлена на противодействие тактике типа impact.

В этой политике также среди критериев используется список ip-адресов из продукта «Гарда NDR». А среди критериев перечислены запросы, которые характерны для данной техники злоумышленника, если мы опираемся на классификатор MITRE ATT&CK.

Мы добавили ключевые запросы, которые могут использоваться злоумышленником, такие как DELETE FROM, DROP TABLE etc.

Еще одна политика направлена на защиту конкретной таблицы в базе данных.

Обычно такими политиками защищаются таблицы, в которых содержится критическая информация для организации, нарушение целостности которой может привести к негативным последствиям. Предположим, у нас есть таблица «Users», содержащая конфиденциальную информацию, такую как имена, адреса, номера телефонов и хэшированные пароли, или таблица: «Transactions», где содержатся записи о транзакциях, включая суммы, даты, отправителей и получателей, или таблица: Orders, содержимое которой – это данные о заказах, включая товары, клиента, статус заказа, стоимость, или таблица: SystemSettings с конфигурациями приложений, доступами, параметрами подключения к внешним системам.

Мы можем включить отдельно журналирование всех операций SELECT, INSERT, UPDATE, DELETE на этой таблице для обнаружения подозрительной активности.

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

Вот основные мотивы интеграции средств защиты сети (NDR) и баз данных (DBF):

Разные уровни угроз

• Сетевая защита предотвращает проникновение извне (DDoS-атаки, сканирование портов, проникновение через уязвимости сетевых протоколов).

• Защита баз данных работает с внутренними угрозами, такими как SQL-инъекции, утечки данных, несанкционированный доступ, ошибки администрирования.

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

Специфические уязвимости баз данных

Базы данных подвержены уникальным типам атак:

• SQL-инъекции. Даже если сеть защищена, веб-приложение может быть уязвимо к SQL-инъекциям.

• Брутфорс к учетным записям базы данных. Злоумышленники могут перебирать пароли к базам данных напрямую.

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

Многие стандарты (ФЗ-187, ФЗ-152, GDPR, HIPAA, PCI DSS) требуют защиты данных на уровне баз данных, включая шифрование, аудит доступа и управление учетными записями.

Логирование и мониторинг

Механизмы базы данных позволяют вести журнал доступа и операций над данными, что недоступно для большинства сетевых инструментов.

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