Простые тесты показали, что существует множество
следов, оставленных в базе данных или сетевых трассировочных файлах, если
была предпринята попытка SQL инъекции. Поэтому все это должно
быть доступно для DBA, чтобы использовать некоторые из вышеупомянутых
источников как основание для политики обнаружения. Некоторые из методов, типа
анализа трассировочных файлов – явные пожиратели ресурсов. Высокоточный аудит и чтение
SQL из SGA очень похожие методы, что позволяет их совместно использовать для аудита базы данных. Конечно, лучшая форма защиты – это аудит вашей базы данных и избежание
использования динамического Sql.
Внутренние трассировочные файлы Oracle.
Oracle может также генерировать файлы трассировки из ядра Oracle,
когда запущен SQL. Это может быть включено на уровне RDBMS,
при установке параметра SQL_TRACE=true в файле init.ora.
Это может также быть включено в случае следующего действия:
ALTER SYSTEM SET SQL_TRACE=TRUE;
Трассировка также может быть включена для текущего сеанса:
ALTER SESSION SET SQL_TRACE=TRUE;
Прежде, чем будет включена трассировка, параметр timed_statistics,
в файле инициализации, должен быть установлен в значение TRUE. Трассировочные
файлы будут записаны в файл, определенный, в файле инициализации, параметром
user_dump_dest.
Давайте создадим файл трассировки для нашего простого примера SQL
инъекции и проанализируем его следующим образом:
Файл трассировки создается с форматом имени: {SID}_ora_{PID).trc.
Формат определяется платформой. В случае трассировочных файлов SQL*Net,
PID является OS PID, и снова это может быть определено
с помощью запроса к представлениям v$session и v$process. Необработанный файл
трассировки может быть прочитан, а рассматриваемый SQL может быть замечен
следующим образом:
Лучшим путем является запись файла трассировки с утилитой, называемой tkprof:
Сгенерированный файл содержит весьма много информации, включая синхронизацию
и идентификаторы пользователей. Синхронизация должна читаться в необработанном
файле трассировки, но пользовательский идентификатор может быть найден в выходных
данных tkprof. Преобразованные выходные данные показывают пакеты
PL/SQL, называемые также динамическими SQL строками:
Пользовательский идентификатор можно прочесть в базе данных следующим образом:
У трассировочных файлов, несомненно, есть перспектива в осуществлении системы
обнаружения SQL инъекций, но у них также существуют некоторые
серьезные проблемы:
· Поскольку файлы трассировки
тоже генерируются основанными на OS PID, то их обслуживание
в реальном времени, для гарантирования от злоупотребления ресурсами, является
очень трудным. Любые долго запущенные сеансы очень легко переполняют диск.
Информация в трассировочных файлах хороша и пригодна к использованию, но
производительные проблемы с генерацией трассировки постоянно наводят на мысль
о том, чтобы не использовать этот метод. Как и в случае с SQL*NET
эти файлы могут использоваться более расчетливо.
Чтение SQL из System Global Area (SGA)
Это может быть наиболее перспективным методом выделения и анализа SQL,
в случае если была сделана попытка SQL инъекции. Причины этого
исключительно из-за того, что – основной элемент Oracle RDBMS,
весь SQL и запущенный PL/SQL, проводит некоторое
время в SQL области в SGA. Однако существует несколько проблем,
чтобы быть уверенным в этом. Во-первых – то, что запрос к SQL области
может интенсивно использовать ресурсы и заставить работать систему на критическом
уровне, а во-вторых, может отсутствовать уже выполненный SQL. Если
база данных запускает тысячи различных SQL, а память, выделенная для
SQL области – не большая, то нечасто используемый SQL
(однажды или дважды) может очень быстро покинуть SQL область.
Постоянные SQL запросы – являются ключевыми в контролировании нападений.
Слишком часто это может приносить вред производительности, и не достаточно
часто вы могли бы что-нибудь пропустить. Если организация использует этот
метод для проверки нападений, то запускать проверки нужно два или три раза
в день, а контролировать и исправлять необходимо как можно чаще.
Снова, как с другими источниками информации, фильтр или синтаксический анализатор
действительно необходимы для анализа SQL, извлеченного для показа
некоторых признаков того, что является легальным, а что нет. Для начала можно
использовать сценарий, проверяющий только существование union
в SQL, фильтрующий некоторых возможных пользователей и сохраняющий
результаты в итоговой таблице, используя команду create
table as select, а далее фильтрующий определенные связанные
таблицы. Хорошее первое приближение было бы должно выдвинуть на первый план
любой SQL, произведенный не sys пользователем с предложением
union, обращающимся к таблице или представлению, принадлежащему
sys. Наш пример делает запрос к представлению all_users,
принадлежащему sys.
Ниже простой пример запроса, извлекающего из SGA, SQL, содержащий
в себе предложение union. Это должно дать читателю идеи о том, как
могут быть прочитаны данные. Далее мы проводим фильтрацию, как описано выше.
Пример был выполнен, как SYS пользователь и как DBSNMP пользователь, пока
эта база данных неоднократно была в выводе(output). Этот метод пока,
кажется, самый простой в использовании и вероятно самый легкий способ реализации
полного средства/сценария для анализа SQL инъекций. Также он имеет
наименьшее количество плохих сторон!
Использование аудита Oracle.
Возможности, доступные в стандартном Oracle аудите – богаты и различны,
но существует множество проблем с его использованием, для обнаружения SQL
инъекций.
Аудит должен использоваться независимо от использования любого из других
методов. Это – устойчивая и полезная система может быть полезной для обнаружения
нападений.
Не так легко обнаружить SQL инъекцию с помощью аудита, скорее
можно отследить явные улики. Например, если аудит был включен для select
access в таблицах DBSNMP.customers и SYS.all_users,
тогда контрольный след должен показать проникновение, в случае использования,
такой как описано в нашем примере, попытки SQL инъекции. Мы
не можем определенно говорить, что использовался union, но доступ с
помощью DBSNMP к ALL_USERS должен быть видим.
Когда хакер пытается предположить, как добавить union, подзапрос или
усекающий комментарий, к существующей SQL строке, то могут быть сгенерированы
SQL ошибки, если он делает это неправильно. И снова это является явной
уликой, а детальный анализ ошибок в контрольном следе и другие действия
тем же самым пользователем в том же самом сеансе могут указывать на то, что
случилось.
Ниже находиться пример использования аудита, для выполняющейся SQL
инъекции. Сначала включите аудит в представлении ALL_USERS и
таблице CUSTOMERS.
Проверьте контрольный след со следующим SQL:
Все это показывает доступ к представлению ALL_USERS и таблице CUSTOMERS
пользователями DBSNMP в одном и том же сеансе. Это также является простым
в написании части SQL, для анализа ошибок в контрольном следе.
Аудит, несомненно, может использоваться, для обнаружения SQL инъекций,
но он требует значительных усилий при определении “хороших” SQL
запросов и параметров настройки аудита для надежного “предположения”
при попытках SQL инъекций.
Триггеры базы данных.
Триггеры базы данных обычно являются следующей линией защиты, когда используется
внутренний аудит Oracle. Нормальные средства аудита работают на уровне
object, или привилегированном уровне, и не могут быть полезны
при определения случившегося на уровне строки. Для этого могут использоваться
триггеры. Их использование влечет за собой программирование триггеров для
каждой таблицы и для каждого действия типа insert, update
или delete. Главный недостаток триггеров это – то, что они
не могут быть написаны для запуска, если команда select используется
против таблицы или представления.
Выделение фактического SQL, используемого для update, delete
, или insert – не возможно. Возможно, создать SQL,
который будет использоваться при запуске триггера изменения таблицы, читая
прежде и после значения для каждой строки и создать триггер запускающийся
для каждой строки.
Ввиду этих ограничений, триггеры базы данных, не всегда полезны в поисках
попыток SQL инъекций.
Высокоточный аудит
С версии 9i, в Oracle представлен высокоточный аудит (FGA).
Эта функция основана на внутренних триггерах, запускающихся при каждом
анализе SQL выражений. Как и высокоточный контроль доступа, (FGA)
основывается на определении предикатов, для ограничения SQL, который
будет ревизоваться. Используя аудитную политику, аудит может быть сфокусирован
на небольшом поднаборе действий, выполненных против определенного набора данных.
Единственное преимущество, которое дает нам эта функция это способность контролировать
команды select на уровне строк. Стандартная обрабатывающая функция,
также фиксирует SQL, так что она может быть хорошим средством, для
проверки SQL инъекций. Действительно, Oracle заявляет
в своей on-line документации этого пакета, что он – идеальный
инструмент для осуществления IDS системы.
Давайте установим простую политику и посмотрим, можем ли мы отловить инъекцию
в нашем примере. Первое требование – то, что таблицы, с установленным против
них FGA, должны генерировать аналитическую статистику. Также должен
использоваться cost-based оптимизатор. Существует
множество проблем с FGA, которые являются факторами неправильного запуска
триггеров, например, если в SQL используется правило проверки RULE.
Сначала проверьте оптимизатор и проанализируйте пример таблицы:
Затем, создайте политику, которая будет каждый раз выполнять выражение, запущенное
против таблицы (в этом случае DBSNMP.CUSTOMERS).
Затем, выполните пример SQL инъекции, и проверьте контрольный след
для любых входов:
Отлично, успех! Динамический SQL показывается, включая предложение
union, присоединенное к системной таблице ALL_USERS.
Использование FGA должно быть расширено к каждой таблице в прикладном
проекте. Тогда должны записываться сообщения, это возвращало бы только те
входы, которые нарушают некоторые из основных правил, определенных вначале,
типа SQL с предложением union, или SQL
со строкой типа ‘x’ = ‘x’.
Вся политика может быть легко сгенерирована, используя следующий SQL:
Некоторые решения по защите от SQL инъекций, можно узнать из
предыдущих статей, но для совершенства, несколько главных идей снова здесь
включены:
Другая причина того, что нельзя определить какие-либо точные цифры это то,
что большинство компаний вероятно даже не знает о том, что кто-то использует
SQL инъекции против их базы данных Oracle. Я надеюсь,
что эта статья дала некоторое понимание проблемы и показала некоторые простые
идеи администраторам баз данных и руководителям служб безопасности, для контролирования
этой проблемы.
Как я и заявлял ранее, одно простое решение – не соединять вашу базу данных Oracle с Internet.
Во-вторых, не используйте динамический SQL или PL/SQL,
а если вы это все- таки делаете, то используйте bind переменные. Также
контролируйте и защищайте данные, насколько это возможно в ОС и сетевой защите.
Простые тесты, показанные выше, показали, что действительно существует множество
следов, оставленных в базе данных или сетевых трассировочных файлах, если
была предпринята попытка SQL инъекции. Поэтому все это должно
быть доступно для DBA, чтобы использовать некоторые из вышеупомянутых
источников как основание для политики обнаружения. Некоторые из методов типа
трассировочных файлов – явные пожиратели ресурсов. Высокоточный аудит и чтение
SQL из SGA очень похожие методы, что позволяет их совместно использовать для аудита.
Конечно, лучшая форма защиты это аудит защиты вашей базы данных и избежание
использования динамического SQL!!!
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания Abnormal Security, основанная в 2019 году, предлагает облачную платформу безопасности электронной почты, которая использует анализ поведенческих данных для выявления и предотвращения атак на электронную почту. Платформа на базе искусственного интеллекта анализирует поведение пользовательских данных, организационную структуру, отношения и бизнес-процессы, чтобы выявить аномальную активность, которая может указывать на кибератаку. Платформа защиты электронной почты Abnormal может предотвратить компрометацию корпоративной электронной почты, атаки на цепочку поставок , мошенничество со счетами, фишинг учетных данных и компрометацию учетной записи электронной почты. Компания также предоставляет инструменты для автоматизации реагирования на инциденты, а платформа дает облачный API для интеграции с корпоративными платформами, такими как Microsoft Office 365, G Suite и Slack.
Копания Apiiro вышла из «скрытого режима» в 2020 году. Ее платформа devsecops переводит жизненный цикл безопасной разработки «от ручного и периодического подхода «разработчики в последнюю очередь» к автоматическому подходу, основанному на оценке риска, «разработчики в первую очередь», написал в блоге соучредитель и генеральный директор Идан Плотник . Платформа Apiiro работает, соединяя все локальные и облачные системы управления версиями и билетами через API. Платформа также предоставляет настраиваемые предопределенные правила управления кодом. Со временем платформа создает инвентарь, «изучая» все продукты, проекты и репозитории. Эти данные позволяют лучше идентифицировать рискованные изменения кода.
Axis Security Application Access Cloud – облачное решение для доступа к приложениям , построенное на принципе нулевого доверия. Он не полагается на наличие агентов, установленных на пользовательских устройствах. Поэтому организации могут подключать пользователей – локальных и удаленных – на любом устройстве к частным приложениям, не затрагивая сеть или сами приложения. Axis вышла из «скрытого режима» в 2020 году.
BreachQuest, вышедшая из «скрытого режима» 25 августа 2021 года, предлагает платформу реагирования на инциденты под названием Priori. Платформа обеспечивает большую наглядность за счет постоянного отслеживания вредоносной активности. Компания утверждает, что Priori может предоставить мгновенную информацию об атаке и о том, какие конечные точки скомпрометированы после обнаружения угрозы.
Cloudrise предоставляет услуги управляемой защиты данных и автоматизации безопасности в формате SaaS. Несмотря на свое название, Cloudrise защищает как облачные, так и локальные данные. Компания утверждает, что может интегрировать защиту данных в проекты цифровой трансформации. Cloudrise автоматизирует рабочие процессы с помощью решений для защиты данных и конфиденциальности. Компания Cloudrise была запущена в октябре 2019 года.
Cylentium утверждает, что ее технология кибер-невидимости может «скрыть» корпоративную или домашнюю сеть и любое подключенное к ней устройство от обнаружения злоумышленниками. Компания называет эту концепцию «нулевой идентичностью». Компания продает свою продукцию предприятиям, потребителям и государственному сектору. Cylentium была запущена в 2020 году.
Компания Deduce , основанная в 2019 году, предлагает два продукта для так называемого «интеллектуального анализа личности». Служба оповещений клиентов отправляет клиентам уведомления о потенциальной компрометации учетной записи, а оценка риска идентификации использует агрегированные данные для оценки риска компрометации учетной записи. Компания использует когнитивные алгоритмы для анализа конфиденциальных данных с более чем 150 000 сайтов и приложений для выявления возможного мошенничества. Deduce заявляет, что использование ее продуктов снижает ущерб от захвата аккаунта более чем на 90%.
Автоматизированная платформа безопасности и соответствия Drata ориентирована на готовность к аудиту по таким стандартам, как SOC 2 или ISO 27001. Drata отслеживает и собирает данные о мерах безопасности, чтобы предоставить доказательства их наличия и работы. Платформа также помогает оптимизировать рабочие процессы. Drata была основана в 2020 году.
FYEO – это платформа для мониторинга угроз и управления доступом для потребителей, предприятий и малого и среднего бизнеса. Компания утверждает, что ее решения для управления учетными данными снимают бремя управления цифровой идентификацией. FYEO Domain Intelligence («FYEO DI») предоставляет услуги мониторинга домена, учетных данных и угроз. FYEO Identity будет предоставлять услуги управления паролями и идентификацией, начиная с четвертого квартала 2021 года. FYEO вышла из «скрытого режима» в 2021 году.
Kronos – платформа прогнозирующей аналитики уязвимостей (PVA) от компании Hive Pro , основанная на четырех основных принципах: предотвращение, обнаружение, реагирование и прогнозирование. Hive Pro автоматизирует и координирует устранение уязвимостей с помощью единого представления. Продукт компании Artemis представляет собой платформу и услугу для тестирования на проникновение на основе данных. Компания Hive Pro была основана в 2019 году.
Израильская компания Infinipoint была основана в 2019 году. Свой основной облачный продукт она называет «идентификация устройства как услуга» или DIaaS , который представляет собой решение для идентификации и определения положения устройства. Продукт интегрируется с аутентификацией SSO и действует как единая точка принуждения для всех корпоративных сервисов. DIaaS использует анализ рисков для обеспечения соблюдения политик, предоставляет статус безопасности устройства как утверждается, устраняет уязвимости «одним щелчком».
Компания Kameleon , занимающаяся производством полупроводников, не имеет собственных фабрик и занимает особое место среди поставщиков средств кибербезопасности. Компания разработала «Блок обработки проактивной безопасности» (ProSPU). Он предназначен для защиты систем при загрузке и для использования в центрах обработки данных, управляемых компьютерах, серверах и системах облачных вычислений. Компания Kameleon была основана в 2019 году.
Облачная платформа безопасности данных Open Raven предназначена для обеспечения большей прозрачности облачных ресурсов. Платформа отображает все облачные хранилища данных, включая теневые облачные учетные записи, и идентифицирует данные, которые они хранят. Затем Open Raven в режиме реального времени отслеживает утечки данных и нарушения политик и предупреждает команды о необходимости исправлений. Open Raven также может отслеживать файлы журналов на предмет конфиденциальной информации, которую следует удалить. Компания вышла из «скрытого режима» в 2020 году.
Компания Satori, основанная в 2019 году, называет свой сервис доступа к данным “DataSecOps”. Целью сервиса является отделение элементов управления безопасностью и конфиденциальностью от архитектуры. Сервис отслеживает, классифицирует и контролирует доступ к конфиденциальным данным. Имеется возможность настроить политики на основе таких критериев, как группы, пользователи, типы данных или схема, чтобы предотвратить несанкционированный доступ, замаскировать конфиденциальные данные или запустить рабочий процесс. Сервис предлагает предварительно настроенные политики для общих правил, таких как GDPR , CCPA и HIPAA .
Компания Scope Security недавно вышла из «скрытого режима», будучи основана в 2019 году. Ее продукт Scope OmniSight нацелен на отрасль здравоохранения и обнаруживает атаки на ИТ-инфраструктуру, клинические системы и системы электронных медицинских записей . Компонент анализа угроз может собирать индикаторы угроз из множества внутренних и сторонних источников, представляя данные через единый портал.
Основным продуктом Strata является платформа Maverics Identity Orchestration Platform . Это распределенная мультиоблачная платформа управления идентификацией. Заявленная цель Strata – обеспечить согласованность в распределенных облачных средах для идентификации пользователей для приложений, развернутых в нескольких облаках и локально. Функции включают в себя решение безопасного гибридного доступа для расширения доступа с нулевым доверием к локальным приложениям для облачных пользователей, уровень абстракции идентификации для лучшего управления идентификацией в мультиоблачной среде и каталог коннекторов для интеграции систем идентификации из популярных облачных систем и систем управления идентификацией. Strata была основана в 2019 году.
SynSaber , запущенная 22 июля 2021 года, предлагает решение для мониторинга промышленных активов и сети. Компания обещает обеспечить «постоянное понимание и осведомленность о состоянии, уязвимостях и угрозах во всех точках промышленной экосистемы, включая IIoT, облако и локальную среду». SynSaber была основана бывшими лидерами Dragos и Crowdstrike.
Traceable называет свой основной продукт на основе искусственного интеллекта чем-то средним между брандмауэром веб-приложений и самозащитой приложений во время выполнения. Компания утверждает, что предлагает точное обнаружение и блокирование угроз путем мониторинга активности приложений и непрерывного обучения, чтобы отличать обычную активность от вредоносной. Продукт интегрируется со шлюзами API. Traceable была основана в июле 2020 года.
Компания Wiz, основанная командой облачной безопасности Microsoft, предлагает решение для обеспечения безопасности в нескольких облаках, рассчитанное на масштабную работу. Компания утверждает, что ее продукт может анализировать все уровни облачного стека для выявления векторов атак с высоким риском и обеспечивать понимание, позволяющее лучше расставлять приоритеты. Wiz использует безагентный подход и может сканировать все виртуальные машины и контейнеры. Wiz вышла из «скрытого режима» в 2020 году.
Работает на CMS “1С-Битрикс: Управление сайтом”
cvvstore valid cc shop