5 июня, пятница 05:18
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Технология защиты от целевых атак

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Технология защиты от целевых атак

    Коллеги, предлагаю познакомиться с реализованной и апробированной нами в КСЗИ "Панцирь+" технологией защиты от целевых атак, презентация которой представлена по ссылке: http://npp-itb.ru/images/docs/alldocs/slides.pdf
    Буду благодарен за высказанное Вами мнение.

  • #2
    Сообщение от Константин Щеглов Посмотреть сообщение
    Буду благодарен за высказанное Вами мнение
    Сто раз высказывали, мне несложно и в стопервый повторить.

    Антивирусная защита, обнаружение поведенческих аномалий, вторжений и т.д., основанные на детектировании вирусов и потенциально опасных событий. СЗИ НСД реализуют разграничение прав доступа между пользователями, не пригодны для защиты от целевых атак.
    Вы говорите "целевая атака", а рассказываете про атаки на операционную систему с помощью уязвимостей нулевого дня. Сомневаюсь, что вы не понимаете разницу,- значит, делаете это сознательно. Нехорошо

    Информационную систему атакуют на прикладном уровне, который средства защиты уровня операционной системы не защищают никак от слова "совсем". И при этом зеродеи используются крайне редко.

    Драйверы КСЗИ «Панцирь+» выполнены как не выгружаемые из системы, их нельзя выгрузить системным процессом или службой.
    Службу КСЗИ «Панцирь+» нельзя остановить с правами администратора
    Как и в любом другом уважающем себя средстве защиты уровня операционной системы. Что ни разу не мешало нарушителям выгружать и отключать их, действую точно так же в ядре операционной системы. Способов доставки вредоносного кода напрямую в ядро, минуя любые наложенные СЗИ - вагон и маленькая тележка.

    Защита от инжектирования кода в процесс (защита от угроз атак заражения процессов, включая системные)
    Браво, вы научились перехватывать операции прямого доступа к памяти сторонних процессов А как насчет внедрения кода напрямую в ядро из-за ошибок обработки адресов callback функций (CVE-2015-1701 и т.п.)? Такие уязвимости появляются регулярно. Из всего перечисленного в презентации от таких атак частично спасает только запрет на запуск сторонних исполняемых файлов, но нет ничего, что спасало бы от эксплуатации этих уязвимостей вредоносным кодом, внедренным в документы DOC и PDF. Антивирусы и HIDS, кстати, с этим справляются (правда, при наличии сигнатур)

    Безусловно, СЗИ уровня операционной системы способны затруднить действия нарушителя (например, помешать исполнению команд операционной системы c помощью SQLI, но примерно в том же объеме нарушителю мешают и остальные меры защиты, которые вы почему-то обозвали "непригодными"

    Комментарий


    • #3
      Благодарю за высказанное Вами в "101" раз мнение.
      Однако не понимаю Вашего тезиса о том, что в документе излагается не защита от целевых атак, а защита от атак на операционную систему.... Странно, что у Вас сложилось подобное мнение, возможно, что это наша недоработка.

      Для иллюстрации своего непонимания Вашего мнения, очень кратко (в развернутом виде все это есть в документе, на который я ссылался выше) изложу реализуемые нами способы защиты от фишинговых атак (на те самые приложения, о которых Вы упомянули, в смысле "совсем").
      Фишинговая атака в большинстве случаев реализуется через почтовое вложение, в котором либо передается зараженный файл, либо ссылка на зараженный сайт. В первом случае, приложение, после прочтения вредоносного файла, реализует заложенные в нем действия, во втором случае, с зараженного файла в память компьютера загружается вредоносная активная страница, в результате чего, браузер наделяется соответствующим вредоносными функциями.
      Основу построения анти-фишинговой защиты в КСЗИ «Панцирь» составляет использование запатентованного технического решения, реализующего контроль доступа к создаваемым файлам. Каждый файл при создании автоматически размечается, в его альтернативный поток помещаются учетные данные создавшего файл субъекта доступа, в данном случае процесса. Разграничительной политикой доступа определяется, какому субъекту к файлам, созданным каким субъектам разрешает доступ, и какой доступ – чтение, запись, исполнении и т.д. Актуальность данного механизма защиты обусловливается тем, что именно в создаваемых файлах хранятся обрабатываемые данные, и именно в создаваемых файлах размещаются записываемые на компьютер вирусы – исполнимые и командные файлы.
      Возможности КСЗИ «Панцирь+» в части защиты от фишинговых атак весьма широки, и главным при этом является то, что не требуется какого-либо детектирования чего-либо.
      Рассмотрим некоторые из этих возможностей.
      1. Любому субъекту доступа (любому процессу) запрещается исполнение любого создаваемого файла, а командным интерпретаторам и чтение любого создаваемого файла.
      2. Браузеру запрещается любой доступ к созданным на компьютере данным иными приложениями.
      3. Только требуемым приложениям разрешается доступ к сохранению и/или открытию почтовых вложений, т.к. существуют приложения с потенциально опасными возможностями, например, архиватор WinRar упаковывает вместе с файлом альтернативный поток, в котором может быть размещен исполнимый, либо командный файл, не видимый пользователю. Целесообразно запретить доступ к почтовым вложения различных приложений.
      Это, своего рода, статичные «песочницы» для корпоративных информационных систем, предполагающие реализацию ограничений на обработку данных потенциально опасными приложениями.
      Реализация в КСЗИ «Панцирь+» динамической песочницы состоит в следующем.
      Ограничивается доступ к созданным (размеченным) файлам, т.е. к обрабатываемым данным, при открытии приложением с высокой вероятностью зараженного файла (критичного файла), например, полученного по электронной почте в виде вложения. Процесс, открывающий такой файл, автоматически помещается в песочницу – ему запрещается доступ ко всем, в том числе и им же, созданным ранее всеми приложениями доверенным размеченным файлам (к обрабатываемым данным). При сохранении файла, обрабатываемого в песочнице, его разметка не изменяется (при следующем прочтении соответствующий процесс опять же будет помещаться в песочницу). Таким образом, приложение, зараженное прочтением критичного файла, не получит доступ к доверенным файлам.
      Режимы обработки файлов в песочнице.
      1. При открытии критичного файла, доступ к доверенным файлам становится невозможен. Критичные файлы обрабатываются изолированно – имеют доступ только к критичным файлам.
      2. При открытии доверенного файла, далее может быть открыт как доверенный, так и критичный файл (эти документы можно обрабатывать вместе, в том числе копировать текст между документами). При открытии критичного, доступ к доверенным запрещается, при сохранении любого открытого файла, будет предложено создать новый файл, который унаследует разметку критичного файла.
      Зараженное при прочтении критичного фала приложение не сможет получить доступ к обрабатываемым доверенным данным.

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

      Как видим, никакого детектирования чего-либо не осуществляется, обрабатываемые данные защищаются в том числе и от атак на уязвимости приложений - браузера, редактора и т.п.
      Как видите, все совсем не так, как Вы думаете, и о чем уже говорите "101" раз!



      Комментарий


      • #4
        Константин Щеглов
        Давайте немного по другому. Представьте, что некто разместил на врачебном форуме информацию о новом презервативе в качестве средства для борьбы с туберкулезом. Конечно понятно, что некий положительный эффект от этого средства (или подхода) скорее всего будет, т.к. ожидаемо снижение количества участников случайных связей подцепивших нечто, снижающее общий иммунитет и, как следствие, оказавшихся более подверженным инфекционным заболеваниям.

        Вы, зачем-то, старательно смешиваете понятия "теплого" и "мягкого". Зачем?
        Насколько я понял (возможно ошибаюсь) СЗИ, которое Вы пытаетесь отпиарить, представляет собой средство пере- и до- определения прав доступа на файловом уровне.
        Возможно, что Ваше СЗИ будет более эффективно, в каких-то случаях, чем эвристические методы антивирусов.
        Возможно, идеи Вашего СЗИ имеет смысл использовать в реальных песочницах для выявления "подозрительного поведения" при открытии файлов. И т.д.
        И поймите, наконец, что совершенно неуместная настойчивость при неправильном позиционировании продукта, сильно вредят имиджу самого продукта, компании производителя и человека/сотрудника, который настойчиво пытается продвинуть продукт совершенно не под тем соусом, под которым бы следовало это делать и, тем более, на тематическом форуме.

        ЗЫ: И, кроме того, ИБ, это достаточно зарегулированная область, где сплошь и рядом, специалисты вынуждены постоянно читать море всяческой нормативной документации (ФЗ, ПП, инструкции, приказы и т.д. от самых разных регуляторов), писать горы внутренней нормативной документации, оценивать модели угроз, нарушителей, эффективность и уместность СЗИ и т.д.
        Т.е. из-за некой "профессиональной заточки", практически любое написанное слово здесь всегда оценивается под разными углами и, в т. ч., с точки зрения уместности и адекватности. Это как бэ местная специфика.
        Возможно, на форуме для домохозяек всё было бы по другому.
        Последний раз редактировалось saches; 30.11.2017, 13:20.

        Комментарий


        • #5
          Пример, конечно, интересный.
          Возможно, что Ваше СЗИ будет более эффективно..... А этого мало для целевых-то атак?
          ... прав доступа на файловом уровне - это был лишь только пример.
          Неуместная настойчивость.... В чем Вы видите настойчивость? Спозиционировали возможности продукта в этой части, предложили для обсуждения. Кому-то надеюсь будет интересно, кто-то не поймет, кто-то не оценит. Это нормально.
          Неправильное позиционирование продукта... Это ведь одна из ряда задач, решаемых нашей СЗИ, которую мы здесь рассматриваем.

          P.S. Дополнил презентацию плакатом, иллюстрирующим реализацию динамической песочницы.

          Комментарий


          • #6
            Сообщение от Константин Щеглов Посмотреть сообщение
            .......Дополнил презентацию плакатом, иллюстрирующим реализацию динамической песочницы.
            А Вы сможете спозиционировать свой продукт в контексте 17-го приказа ФСТЭК (наверное, имеет смысл раздел III и приложение №2)?
            И, желательно, что бы было понятно, какие конкретно требования ФСТЭК Ваше СЗИ закрывает.

            Комментарий


            • #7
              Да, конечно, у нас это даже прописано в ТУ, на соответствие которому сертифицировано большинство механизмов защиты, т.к. требований к таким механизмам нет в РД.
              Приглашаю, можете зайти на сайт продукта по ссылке: http://npp-itb.ru/products/armourp (там это и многое другое, относящееся к КСЗИ "Панцирь+" как к СЗИ НСД).
              Но здесь мы пытаемся рассмотреть иную "историю".

              Комментарий


              • #8
                Константин Щеглов
                Ну тогда, если подходить формально, Ваше СЗИ ничем не отличается от других СЗИ, имеющих точно такой же сертификат.
                Но тогда, что бы сделать выбор именно Вашего продукта, надо понять чем он всё же отличается от других.
                Например,он может отличаться ценой, или еще какими-то потребительскими свойствами.
                Есть какие-либо объективные оценки сравнения эффективности вашего СЗИ с другими?
                Например, существует традиционный способ сравнения антивирусов по %% кол-ву идентифицируемых вирусов - https://www.av-comparatives.org/ .
                Наверное, можно замутить что-то похожее по вылавливанию, например, зеродейев разными СЗИ и песочницами.
                Т.е. нужна некая "линейка" на основании которой, можно было бы сравнивать разные СЗИ. И была бы конкретная "фактура", что бы пиарить Ваш продукт.
                Может коллеги еще что предложат.

                ЗЫ: Кстати, закос про то, что антивирус не нужен, наверное, не самый удачный, т.к. формально, все регуляторы по ИБ требуют установки средств АВЗ на "всё, что двигается". Как некое дополнение, для защиты от зеродейев, может и прокатит, но нужна статистика.
                Последний раз редактировалось saches; 30.11.2017, 15:44.

                Комментарий


                • #9
                  Спасибо, очень важный момент.
                  Формально наша СЗИ отличается от всех тем, что все механизмы защиты сертифицированы, большинство по ТУ, т.е. могут легитимно использоваться при соответствующих требованиях.
                  Всем отличается и механизмами и возможностями. Не случайно реализовано 8 запатентованных нами технических решений. Материалов по приведенной ранее ссылке предостаточно. Другое дело, надо об этом рассказать при условии, что тебя захотят услышать.
                  Вот мы провели пентест своей СЗИ, а рассматривались наиболее актуальные современные угрозы атак, которые априори должны включаться в соответствующую модель угроз, результаты испытаний выложены по ссылке: http://www.npp-itb.ru/images/docs/alldocs/ZUCA.pdf
                  так большиство из этих задач иные СЗИ НСД не решат, так как они построены иным образом. Это ли не обоснование?
                  А Вы верите в возможность осмысленного сравнения антивирусов? Задумайтесь над тем, что их имеет смысл тестировать только на неизвестных вирусах, т.е. в предположении о том, что разработчики антивирусов узнают о новых вирусах последними!
                  Пентест мы проводили с установленным одновременно с Панцирем известным антивирусом. Делится впечатлениями не стану, но Панцирь нужен. Интересно было поставить на эвристику процесс svchost, наиболее заражаемый злодеями, антивирус "сошел с ума".
                  Относительно требований к АВЗ. Мы говорим о целесообразности использовать подобные решения в комплексе, т.к. они решают различные задачи различными способами и дополняют друг друга (есть приличный опыт подобного, пришлось адаптироваться, чтобы не убить слабую машину при включении сигнатурного анализатора). Кроме того, регуляторы требует использовать АВЗ по понятным причинам - а чем еще защищать? Вот мы предложили свое решение.
                  А вообще, если коллеги подскажут что-то дельное в этой части, было бы здорово!

                  Комментарий


                  • #10
                    Сообщение от Константин Щеглов Посмотреть сообщение
                    Задумайтесь над тем, что их имеет смысл тестировать только на неизвестных вирусах, т.е. в предположении о том, что разработчики антивирусов узнают о новых вирусах последними!
                    Это далеко не так (хотя такой тест тоже проводится и имеет определённый практический смысл). Есть большая разница между детектировать конкретную угрозу, иметь арсенал борьбы с ней (вылечить / расшифровать файл), что умеет сигнатурный антивирус И предотвратить заражение, но ничего не сказать про угрозу (что умеет ваше СЗ) и не уметь "вылечить" файл, когда проблема уже произошла. Более того есть гораздо более эффективные механизмы чем реализация локальных песочниц. Кстати, описанные вами сценарии работы значительно устарели (рабочая станция на базе ОС Windows для решения широкого класса задач, работа с письмами, с файлами и ссылками), хотя, конечно, ещё много и где такой сценарий используется. В прикладной контур, где действительно ведётся работа с важной информацией не присылают письма и ссылки. Поэтому точно так же как вы говорите про бесполезность антивируса, можно говорить и про ваше СЗ, т.к. возможности реализации большинства атак, о которых вы говорите, за счёт изоляции приложений на сетевом уровне и даже на уровне виртуализации (см. Qubes OS) и сегментации сети быть вообще не должно.

                    В связи со всем этим и есть некоторый скептицизм коллег.

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

                    Кстати, в Windows 10 многие механизмы защиты, что у вас описаны уже появились, а продвинутые пользователи давно уже используют EMET:

                    Комментарий


                    • #11
                      Сообщение от Константин Щеглов Посмотреть сообщение
                      Для иллюстрации своего непонимания Вашего мнения, очень кратко (в развернутом виде все это есть в документе, на который я ссылался выше) изложу реализуемые нами способы защиты от фишинговых атак (на те самые приложения, о которых Вы упомянули, в смысле "совсем").


                      Не надо про фишинг. ​​​​​​Берем систему ДБО. Доступ через веб-портал. На портале SQLI. Через SQLI получаем доступ к таблицам СУБД Oracle c правами dbo. Имея права dbo, получаем доступ к личным кабинетам пользователей, номерам телефонов, шаблонам периодических платежей. В шаблонах изменяем реквизиты получателей, в личных кабинетах заменяем контакоеые телефоны клиентов на свой номер. Все, все периодические платежи с этого момента направляются не реальным получателям, а нам.

                      Это - типичная целевая атака на систему ДБО. Такие атаки (а ни разу не примитивный фишинг) называются атаками намприкладном уровне. Все лействия нарушителя выполняются на веб-сервере ДБО с помощью HTTP-запросов. Все манипулирование данными выполняется в таблицах СУБД средствами СУБД через внедрение SQL-запросов в значения параметров HTTP-запросов. Никакого доступа к ОС, никакого запуска сторонних файлов.

                      Как именно ваше решение защитит данную систему от такой целевой атаки? Можно ли при этом утверждать, что оно защищает систему от целевой атаки, а WAF (который преднащначен для защиты именно от таких атак) для защиты от целевых атак непр
                      Последний раз редактировалось malotavr; 30.11.2017, 22:26.

                      Комментарий


                      • #12
                        Спасибо, про ДБО интересно. Сейчас не готов сказать, что мы можем "зацепить" при атаке на получение прав dbo. Нужно промоделировать и посмотреть аудит, кто (что) при этом к чему обращается.

                        Комментарий


                        • #13
                          Сообщение от malotavr Посмотреть сообщение
                          Через SQLI получаем доступ к таблицам СУБД Oracle c правами dbo.
                          Просто интересно для понимания: dbo. это ведь указание на табличное пространство (схему), а системная роль, вроде как DBA? В любом случае интересно, действительно ли, до сих пор в современных системах ДБО применяются настолько высоко привилегированные пользователи для работы с данными? Или в Oracle всё ещё находят баги, позволяющие путём SQLI получить контекст высоко привилегированного пользователя?

                          Касательно приведённого примера с ДБО и по теме в части целевых атак: они могут быть и на операционную систему или офисные приложения, чтобы получить плацдарм для дальнейшего развития атаки или даже сразу получить права администратора, так что в общем случае описанное СЗ может считаться для некоторых сценариев защитой и от целевых атак. Даже на самом сервере ДБО, бывает администратор качает незнамо что, а потом запускает, поэтому теоретически можно говорить и про целевые атаки, но это, конечно, притягивание за уши. )))

                          Комментарий


                          • #14
                            Сообщение от Zuz Посмотреть сообщение
                            Просто интересно для понимания: dbo. это ведь указание на табличное пространство (схему), а системная роль, вроде как DBA?
                            ...
                            Касательно приведённого примера с ДБО и по теме в части целевых атак: они могут быть и на операционную систему или офисные приложения, чтобы получить плацдарм для дальнейшего развития атаки или даже сразу получить права администратора, так что в общем случае...
                            1. Ошибся
                            2. Конечно. Я комментировал слайд, в котором прочие средства защиты названы непригодными для защиты от целевых атак, и привел контрпример именно к этому слайду.

                            Я бы не стал комментиррвать, но в связи с ФЗ-187 некоторые вендоры стали слишком активно поднимать тему "наш продукт - это все, что вам нужно для защиты от APT". Некоторые заказчики верят

                            Комментарий


                            • #15
                              Коллега, почему в отношении нас Вы так "воинственно" настроены? Вы "передергиваете", говоря о нашей позиции о непригодных средствах, в последних слайдах презентации мы говорим о другом - о целесообразности комплексирования решений. Любая технология защиты имеет свои ограничения, что и обусловливает целесообразность их комплексирования. Давайте разберемся.

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

                              По поводу SQL-инъекций бегло посмотрели (на это не хватило времени, сейчас анализируем защиту средств виртуализации, там много интересного), так там мы тоже что-то (и существенно) можем, по результатам исследований напишу.
                              Давайте обсуждать без ненужных эмоций, по делу. Как некоторые коллеги здесь говорят, мы пиарим, так пиарят в нашей стране иным образом (думаю, Вы знаете как, по крайней мере не на форуме специалистов). А вот, обсуждая на таком форуме, можно что-то узнать (человек, который утверждает, что все знает, дурак), обобщить и осознать, понять, что ранее не понимал!

                              Комментарий


                              • #16
                                Сообщение от Константин Щеглов Посмотреть сообщение
                                Коллега, почему в отношении нас Вы так "воинственно" настроены? Вы "передергиваете", говоря о нашей позиции о непригодных средствах, в последних слайдах презентации мы говорим о другом - о целесообразности комплексирования решений. Любая технология защиты имеет свои ограничения, что и обусловливает целесообразность их комплексирования. Давайте разберемся.

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

                                По поводу SQL-инъекций бегло посмотрели (на это не хватило времени, сейчас анализируем защиту средств виртуализации, там много интересного), так там мы тоже что-то (и существенно) можем, по результатам исследований напишу.
                                Давайте обсуждать без ненужных эмоций, по делу. Как некоторые коллеги здесь говорят, мы пиарим, так пиарят в нашей стране иным образом (думаю, Вы знаете как, по крайней мере не на форуме специалистов). А вот, обсуждая на таком форуме, можно что-то узнать (человек, который утверждает, что все знает, дурак), обобщить и осознать, понять, что ранее не понимал!
                                А где вы эмоции разглядели? Вы выложили материал и спросили мнение - я вам этот мнение напомнил, благо не в первый раз подобный материал обсуждаем.

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

                                Комментарий


                                • #17
                                  Сообщение от malotavr Посмотреть сообщение
                                  Я комментировал слайд, в котором прочие средства защиты названы непригодными для защиты от целевых атак, и привел контрпример именно к этому слайду.
                                  Перечитал, проникся, полностью поддерживаю!

                                  Комментарий


                                  • #18
                                    Коллеги, спасибо, ценю Ваше мнение. Для того и размещаем информацию на форумах специалистов (это не маркетинговые материалы), нам здесь нужен не пиар (это уже потом), а апробация наших решений специалистами (все мы учимся, и это нормально)! Согласен с тем, что надо более четко позиционировать исследованные возможности системы, учтем.
                                    В части возможностей. Защита рабочих станций, файл-сервера, почтового сервера нам понятна.
                                    Речь зашла о БД (СУБД). Пока этот вопрос не исследовали, "руки не дошли".
                                    Вопрос (если можете, ответьте) как злодей используют SQL инъекцию (естественно, сами разберемся, но Ваш ответ, как специалистов в этом вопросе, может существенно сократить продолжительность наших исследований)? Хотелось бы понять несколько самых распространенных сценариев, чтобы наложить на них наши возможности (если удастся). Понятно, что создать новый файл, а уж тем более исполнить (исполнимый или командный) мы не позволим, равно, как и создать новую инструкцию. Если подскажете, буду весьма благодарен. Общее дело делаем! Спасибо.

                                    Комментарий


                                    • #19
                                      Добавили в презентацию http://npp-itb.ru/images/docs/alldocs/slides.pdf
                                      материалы по реализации защиты систем виртуализации.

                                      Комментарий


                                      • #20
                                        Сообщение от Zuz Посмотреть сообщение
                                        Просто интересно для понимания: dbo. это ведь указание на табличное пространство (схему), а системная роль, вроде как DBA? В любом случае интересно, действительно ли, до сих пор в современных системах ДБО применяются настолько высоко привилегированные пользователи для работы с данными? Или в Oracle всё ещё находят баги, позволяющие путём SQLI получить контекст высоко привилегированного пользователя?
                                        В данном случае не sysdba (system database administrator), а именно и в частности dbo (database owner -- точнее конечно было бы назвать его schema owner). И да, действительно, есть как минимум одна распространенная система ДБО (по имени не буду называть, но очевидно что она не Oracle-специфичная, а "работает на любых БД"), которая из контекста www-шлюза запускает не избранные хранимые процедуры с сессионными идентификаторами (и права грантованы только на exec только этих процедур, и первой строкой exec проверяется валидность сессии конечного клиента), а делает прямые запросы к табличным данным, и не только "видит" все таблицы, но и может модифицировать "бесследно".

                                        Конкретных частных атак именно на сервер ДБО не слышал (может, плохо слушал), но теоретически они в этой конфигурации (запуск веб-сервера с привилегиями schema owner) представляются возможными.

                                        Конкретно про инъекции именно через POST-параметры в именно ораклиные вызовы, это теоретически возможно тоже не всегда, а именно только в том случае, если www-шлюз конструирует sql запросы динамически (или вызывает хранимые процедуры, в которых запросы строятся динамически через execute immediate), а не исполняет статические скомпилированные через prepare с параметрами, в последнем случае опасности инъекции нет.

                                        /kiv

                                        Комментарий


                                        • #21
                                          Добавили в презентацию описание нескольких новых механизмов защиты
                                          и более четкое позиционирование системы защиты:

                                          http://npp-itb.ru/images/docs/alldocs/slides.pdf

                                          Комментарий


                                          • #22
                                            Сообщение от malotavr Посмотреть сообщение
                                            Суть мнения очень проста: маркетинговые материалы не должны вводить в заблуждение потенциального потребителя.
                                            Я вот наконец прочитал всю презентацию, и вот что скажу. Там в преамбуле верно отмечено, что защитой КИС занимаются более-менее профессионалы.

                                            И каждый из нас, если не сформулировал, то по крайней мере "на органолептическом уровне" знает, что все мало-мальски ценные программы не только читают/модифицируют данные, но управляются данными; в том числе - данными, которые ими же и модифицированы. В применении к упомянутому выше execute immediate -- мне стоило в свое время изрядных трудов обойтись без него в такой примитивной системе, как веб-банкклиент.

                                            Со всеми вытекающими

                                            /kiv

                                            Комментарий


                                            • #23
                                              Провели вебинар по технологическим особенностям наших разработок (с последнего дня присутствия на этом форуме многое, что изменилось, многое, что стали позиционировать по иному).
                                              Запись вебинара по ссылке: http://npp-itb.ru/news
                                              Предлагаю познакомиться с этим материалом, оценить эффективность реализованной защиты в нашем сертифицированном решении.
                                              Также "вышла в свет" наша система защиты данных для домашних компьютеров, которая сейчас модернизируется для защиты банкоматов и POS- систем.
                                              Эта система также кратко рассматривается на вебинаре.

                                              Комментарий


                                              • #24
                                                На сайте разместили презентацию, кратко излагающую отличия возможностей нашей системы от иных сертифицированных СЗИ от НСД http://www.npp-itb.ru/images/docs/alldocs/otlich.pdf, а они существенны. Отличия рассмотрены применительно к защите от целевых атак. Предлагаю познакомиться, лишним не будет.
                                                К слову, завершили разработку очень простой в настройке, но при этом весьма эффективной системы защиты от вирусных, фишинговых атак, атак вымогателей и т.д. Страница проекта (есть описание, презентация, демо-версия):http://www.npp-itb.ru/products/sz-data-prot
                                                Буду признателен за комментарии.

                                                Комментарий

                                                Обработка...
                                                X