Безопасность HTML5 – часть вторая piratesccru, track2shopcc

Данный документ содержит выдержки из магистерской диссертации Майкла Шмидта. Здесь отражены рассмотренные в диссертации аспекты HTML5, касающиеся безопасности.
До HTML5 сайты могли заставлять ПА делать XMLHttpRequest-запросы лишь в пределах их собственного домена (из-за политики ограничения домена). Поэтому получать доступ к ресурсам вроде обновлений для частей веб-страницы было возможно только в пределах исходного домена, что ограничивало веб-разработчиков. Это представляло особенную проблему для веб-приложений, которые состоят из нескольких частей, отображающих данные с различных доменов. Загрузка и обновление этих данных были возможны лишь через исходный домен, так что XMLHttpRequest-запросы приходилось присылать на исходный сервер. Этот сервер должен был обрабатывать запрос, загружать данные с других доменов и передавать их назад, браузеру. Такая маршрутизация (называемая также Server-Side Proxying, т. е. Проксирование на стороне сервера) приводила к высокой нагрузке на сервера, а также усложняла и замедляла обновление страниц или их частей.
С приходом HTML5 ситуация изменилась. HTML5 позволяет посылать XMLHttpRequest-запросы между доменами, если определен HTTP-заголовок “Access-Control-Allow-Origin”. При некотором значении этого заголовка, XMLHttpRequest-запрос, посланный Java-скриптом с одного домена, может получить доступ к сайту на другом домене. Веб-приложение, состоящее из множества частей, находящихся на различных доменах, может также посылать XMLHttpRequest-запросы другим доменам, чтобы обновлять данные в браузере. Это снижает трафик между веб-серверами и упрощает реализацию.
Решение о том, может ли JavaScript в ходе XMLHttpRequest-запроса получить данные не от исходного домена, принимается ПА. То есть, ПА сначала делает запрос к другому домену, а затем осуществляет контроль доступа на основе заголовка Access-Control-Allow-Origin. Этот заголовок определяет, может ли JavaScript получить доступ к ответу на запрос или нет. Таким образом, веб-сервер определяет этим заголовком, каким доменам разрешен доступ к его домену путем междоменных запросов. Если данный заголовок не содержит запрашивающий домен или вовсе не определен, браузер не даст JavaScript получить ответ на запрос. Следующий пример перехваченного сетевого трафика показывает HTTP-ответ сервера из внешнего домена external.csnc.ch с установленным заголовком контроля доступа.
Данный фрагмент показывает, что заголовок Access-Control-Allow-Origin имеет значение internal.csnc.ch. Это означает, что лишь сайты с домена internal.csnc.ch имеют право доступа к external.csnc.ch через XMLHttpRequest.
В предыдущих параграфах было дано верное, но сокращенное описание Междоменного Разделения Ресурсов (CORS). На самом деле, в CORS существует больше деталей и посылается больше сообщений при определенных обстоятельствах, например, предварительный (preflight) запрос/ответ. Раздел 5.3.1 описывает шаги обработки CORS более подробно. Кроме того, в разделе 5.2.1 можно найти демонстрационное приложение, которое иллюстрирует междоменный запрос (Cross-Origin Request, COR), а также соответствующий дамп сетевого трафика. Это демонстрационное приложение можно использовать для загрузки произвольного URI через XMLHttpRequest и отображения результата на веб-странице (если целевой сайт посылает в ответе должным образом определенный заголовок Access-Control-Allow-Origin).
Вместе с появлением этой новой возможности HTML5 возникают и новые уязвимости. Фундаментальная проблема безопасности заключается в том, что междоменные XMLHttpRequest-запросы можно посылать, не спрашивая разрешения у пользователя. На самом деле запросы посылаются даже без уведомления пользователя. Это можно использовать для нарушения требования безопасности “Контроль доступа” через злоупотребление пользовательской сессией. Это означает, что данные запросы делаются от лица жертвы, которая может оказаться аутентифицированным пользователем. Происходит злоупотребление пользовательской сессией, что нарушает требование безопасности “Безопасное управление сессиями”.
Вслед за “Контролем доступа” нарушается следующее требование безопасности, “Конфиденциальность”. Это делается либо прямым доступом к ресурсам через обход “Контроля доступа”, либо косвенно, если доступ к конфиденциальным данным получается путем злоупотребления пользовательскими сессиями для сбора информации о жертве.
Другая проблема, связанная с CORS, заключается в том, что источник данных больше не ограничен сервером сайта. Браузер может загружать данные из других источников, которые не могут быть проверены исходным доменом и должны считаться недоверенными. Таким образом, данные, полученные через CORS, должны проверяться на стороне клиента. Эта проблема (требование безопасности «Проверка данных») связана также с технологиями Web Socket API (см. раздел 2.7) и Web Messaging (раздел 2.5) и поэтому рассматривается лишь однажды, в разделе 2.5.1.
В этом подразделе приводятся некоторые сценарии эксплуатации злоумышленником проблем безопасности, описанных в разделе 2.2.1. Сценарии атак для следующих четырех угроз будут даны в параграфах 2.2.2.1-2.2.2.4 для демонстрации эффекта этих угроз. Идеи сценариев атак взяты из [35]. В следующем списке перечислены как угрозы, так и нарушаемые ими требования безопасности:
В данном сценарии предполагается, что внутренний сайт доступен лишь из Интранет (корпоративной сети). Доступ к сайту из Интернет блокируется файрволом. Поскольку этот Интранет-сайт предоставляет сервисы нескольким внутренним приложениям, разработчик решил установить значение заголовка Access-Control-Allow-Origin, равное *, чтобы сделать его доступным для всех Интранет-приложений. Это было сделано, поскольку предполагалось, что сайт доступен только из Интранет. Соответствующая топология сети показана в виде высокоуровневой диаграммы в разделе 5.1.2. Эта диаграмма показывает вовлеченные сетевые устройства и периметр безопасности, а также положение атакующего и жертвы.
Для доступа к внутреннему сайту из Интернет, атакующий создает свой сайт с вредоносным JavaScript-кодом и обманом заставляет сотрудника соответствующей компании зайти на этот вредоносный сайт из Интранет. Как только сотрудник открывает вредоносный сайт, JavaScript-код делает XMLHttpRequest-запрос к корпоративному сайту. Ответ посылается обратно на сайт, контролируемый атакующим. Итак, атакующий способен получать доступ к корпоративным приложениям из Интернет посредством XMLHttpRequest-запросов. Для осуществления данной атаки нужно знать URI внутреннего сайта или попытаться определить его, используя техники, описанные в разделе 2.2.2.3. Рисунок 3 иллюстрирует данную атаку в виде диаграммы последовательности.
Небольшая вариация атаки имеет место в случае, когда сайт выглядит по-разному при доступе из Интранет и Интернет. Тогда в результате атаки Интранет-контент можно получать из Интернет.
Этот сценарий описывает то, как междоменные запросы можно использовать для злоупотребления ПА жертвы и запуска атак на веб-сервер. Атакующий создает вредоносный сайт или каким-либо образом размещает вредоносный контент на популярном сайте и обманом заставляет пользователя посетить этот сайт. При этом, помимо обычного контента, ПА получает скрытый JavaScript. После загрузки JavaScript-код посылает XMLHttpRequest-запросы и атакует другой сайт. Логи атакуемого веб-сервера покажут, что атаку запустил пользователь, зашедший на вредоносный сайт, что, разумеется, неверно. В разделе 5.1.4 размещена высокоуровневая диаграмма, которая показывает предполагаемую для этой атаки топологию. Если сайт атакующего откроет много пользователей сразу, против атакуемого сайта можно запустить DDoS-атаку. Даже если заголовок Access-Control-Allow-Origin не определен, запросы будут посылаться на веб-сервер и обрабатываться.
DDoS-атаки возможны и средствами HTML4. Однако, HTML5 делает эти атаки гораздо более эффективными. Запросы с использованием XMLHttpRequest по сравнению со стандартными GET-запросами могут посылаться быстрее [36] (более подробно DDoS-атака через комбинацию CORS и Web Workers описана в разделе 2.9.1).
Междоменные запросы можно использовать для определения существования того или иного внутреннего доменного имени, даже если заголовок Access-Control-Allow-Origin не определен или ограничен конкретными доменами. Это можно осуществить, посылая XMLHttpRequest-запрос на произвольные доменные имена и заключая по времени отклика факт наличия или отсутствия домена.
Данная атака демонстрируется POC-приложением, которое описано более подробно в разделе 5.2.2. Это приложение позволяет посылать произвольные запросы на URI с помощью XMLHttpRequest и отображать время отклика. В зависимости от времени отклика можно сделать некоторые выводы. Запрос, посылаемый на URI, имеет различное время отклика в трех разных случаях:
Таблица 1 резюмирует это поведение и показывает, какая дополнительная информация может быть получена из этих трех различных состояний (время отклика в ходе POC-тестов указано в скобках из-за возможных погрешностей):
Возможно определить и другую информацию, вроде прочих 40X заголовков и того, что домен существует, но на нем не запущен веб-сервер. Однако, в этом случае времена отклика будут отличаться незначительно, то есть, чем больше разных характеристик мы пытаемся определить, тем менее точны будут результаты.
Еще одна проблема, которую может создать CORS, – возможность создания удаленного веб-шелла. Если в приложении найдена уязвимость типа “Межсайтовый скриптинг” (XSS), атакующий может делать в приложении то же, что обычный пользователь. Если атакующий может внедрить JavaScript-код, он может запустить обратный шелл с помощью POC-инструментов вроде “Shell of the Future” [37]. Одна из главных функций этого обратного веб-шелла – похищение сессии пользователя через его ПА. XMLHttpRequest используется для запросов и получения содержимого сайтов. Другими словами, атакующий имеет соединение с ПА жертвы и использует ее ПА в качестве “прокси”. Большое преимущество по сравнению с обычной кражей сессионного куки состоит в том, что эта атака работает для приложений, недоступных атакующему напрямую, например, внутренних приложений (подобные атаки уже были возможны средствами технологий HTML4; XSS-Shell [38] тому пример. Но CORS делает эти атаки проще и мощнее).
Справиться со всеми описанными атаками через безопасную реализацию только серверной стороны невозможно. Первые два пункта следующего списка помогают только против угрозы обхода контроля доступа, а третий позволяет обнаруживать DDoS.
Угрозы удаленной атаки на веб-сервер, сбора информации, установления удаленного шелла, раскрытия конфиденциальной информации и создания веб-ботнета не могут быть полностью преодолены путем безопасной реализации. Таким образом можно предотвратить только обход контроля доступа. Остальные угрозы нужно принять как данность или смягчать путем использования других сервисов безопасности.
Особое внимание нужно обратить на возможность атаки “внедрение заголовка”. Например,
Строка %0A%0D вставит дополнительный перенос строки в ответ и заставит браузер думать, что заголовок Access-Control-Allow-Origin был установлен сервером. Если инъекция заголовка возможна, атакующий способен переопределить или установить заголовок Access-Control-Allow-Origin.
До HTML5 веб-приложения могли хранить данные на стороне клиента лишь через механизм куки. Этот способ имеет два больших недостатка. Первый заключается в том, что размер куки сильно ограничен (4K в одном куки / 20 куки на домен [39]), а второй – в том, что куки передаются вместе с каждым запросом. Для того, чтобы обойти это ограничение и сделать возможными оффлайн-приложения, HTML5 вводит концепцию локального хранилища, названную Web Storage (Веб-Хранилище). Web Storage предоставляет сайту возможность сохранять данные на компьютере пользователя и впоследствии обращаться к ним через JavaScript. Размер локального хранилища зависит от реализации браузера, но рекомендованный размер – 5 мегабайт на домен. В первой спецификации HTML5 определены следующие типы веб-хранилища1:
Хранение данных в куки отличается еще и тем, что значения из Локального Хранилища не посылаются на сервер вместе с каждым запросом. Куки имеют срок хранения, а атрибуты Локального Хранилища – нет. Атрибуты Локального Хранилища защищены политикой ограничения домена: значения, сохраненные в HTTP-соединении, недоступны в HTTPS-соединении. Напротив, куки, установленные в HTTP-соединении, посылаются в HTTPS-соединении, если совпадает имя домена.
В разделе 5.2.3 показано POC-приложение, использующее Локальное Хранилище. Это приложение позволяет загружать данные из Локального Хранилища и сохранять их туда. Разграничение Локальных Хранилищ для разных доменов проиллюстрировано в том же разделе. В разделе 5.3.2 показаны несколько примеров JavaScript-кода, получающего доступ к Локальному Хранилищу. (Замечание: Глобальное Хранилище, которое было определено ранее в рабочих проектах HTML5, удалено из текущей спецификации [40]; по этой причине влияние Глобального Хранилища на безопасность рассматриваться здесь не будет).
Главная проблема безопасности, связанная с Локальным Хранилищем, в том, что пользователь не знает, какие данные в нем хранятся. Пользователь не способен контролировать хранилище и, соответственно, доступ к хранящимся в нем данным. Весь доступ производится через JavaScript, поэтому для получения прозрачного для пользователя доступа ко всем элементам хранилища достаточно запустить некоторый JavaScript-код в нужном домене.
Лишь исходный домен имеет права на доступ к данным из Web Storage и на манипуляцию ими. Однако, если атакующий сможет внедрить JavaScript-код, требования безопасности “Защита данных”, “Целостность” и “Конфиденциальность” подвергнутся опасности из-за возможности обхода контроля доступа. Вредоносный JavaScript-код может манипулировать данными или посылать их на другие домены.
Локальное Хранилище рождает новые угрозы, которые описаны в следующем списке. Список, кроме того, показывает, какие требования безопасности при этом нарушаются. Сценарии трех соответствующих атак приведены в разделах 2.3.2.1-2.3.2.3, чтобы продемонстрировать, как Локальное Хранилище может эксплуатироваться атакующим.
HTTP является протоколом без сохранения состояния (stateless), поэтому управление состояниями должно осуществляться на более высоких уровнях. Для этого в веб-приложениях обыкновенно используются куки сессии, которые хранят длинный непредсказуемый маркер. Маркер посылается на веб-сервер, чтобы тот мог опознать пользователя и соответствующую ему сессию.
Тем не менее, проблема такого решения в том, что сессионную куки можно украсть в ходе XSS-атаки. Если атакующему удастся внедрить в веб-приложение следующий код, то он сможет воровать сессионный куки.
Это справедливо и для HTML5, но идентификатор сессии теперь может также храниться в Web Storage. В этом случае атакующему нужно внедрить в веб-приложение следующий код для кражи идентификатора сессии и перехвата сессии пользователя:
Как видно, XSS по прежнему может быть использован для кражи идентификаторов сессий и перехвата сессий пользователей. HTML5 Web Storage ничего не изменил в данном вопросе, лишь слегка поменялась используемая JavaScript-технология. Правда, атакующему приходится быть более точным, ему необходимо знать имя переменной.
Кроме того, для куки можно использовать флаг HTTPonly, чтобы предотвратить доступ к куки через JavaScript, что делает кражу куки (идентификатора сессии) через XSS невозможной. Отсутствие этого HTTPonly флага – другой недостаток хранения идентификаторов в Локальном Хранилище. Дополнительный слой защиты, который обеспечивается флагом HTTPonly, не может быть использован для идентификаторов в Локальном Хранилище.
Как показано в сценарии 1, для доступа к объектам Локального Хранилища достаточно эксплуатировать XSS-уязвимость. Это особенно опасно в случае, когда на стороне клиента хранятся конфиденциальные данные. Атакующий может считать все содержимое Локального Хранилища домена, эксплуатируя XSS-уязвимость.
Если сервер не имеет XSS-уязвимостей, атакующий может заставить пользователя обратиться к веб-приложению через вредоносное сетевое устройство. Это сетевое устройство манипулирует ответами сервера и внедряет в них JavaScript-код, считывающий информацию из Локального Хранилища для соответствующего домена. Атакующему больше не нужно искать уязвимости в веб-приложении. Он может просто атаковать ПА напрямую. На рисунке 5 показана диаграмма последовательности, которая иллюстрирует эту атаку.
Другой проблематичный момент возникает, когда разные веб-авторы используют один и тот же домен и приложения различаются лишь путем в пределах домена. Локальное Хранилище тогда делится между этими приложениями. Не существует способа ограничить доступ к Локальному Хранилищу на основе пути. Итак, усли XSS-уязвимость найдена в приложении www.csnc.ch/app1/, становится возможным читать данные, сохраненные приложением www.csnc.ch/app2/.
Отслеживание пользователя, основаное на куки, – обычный способ идентификации пользователей, посещающих сайт. Вместе с Локальным Хранилищем в HTML5 появляется альтернативная возможность хранить информацию о посетителях сайта. Сайт может хранить информацию для отслеживания пользователей в ПА клиентов и коррелировать пользовательские сессии. Коварность здесь кроется в том, что Локальное Хранилище не удаляется во всех ПА при очистке истории (см. раздел 5.4.1 для обзора поведения разных браузеров). Пользователи, пытающиеся очистить кэш своих ПА, могут не знать про Локальное Хранилище. Вечные куки, уже упоминавшиеся во вступлении, используют Локальное Хранилище как одну из возможностей для отслеживания пользователя.
Использование Локального Хранилища приносит определенную выгоду, но открывает двери для атак, упоминавшихся выше. Есть несколько моментов, которые могут пойти не так, поэтому разработчикам нужно аккуратно реализовывать доступ к атрибутам локального хранилища. Для безопасного использования Локального Хранилища в веб-приложениях необходимо рассмотреть следующие пункты.
Тем не менее, угрозы отслеживания пользователя и постоянных векторов атак все еще остаются в силе и не могут быть нивелированы поставщиком веб-приложений через безопасную реализацию.
1 Изначально стандарт Web SQL database был частью спецификации HTML5. Но в данном документе он не рассматривается, поскольку на момент написания будущее этого стандарта было туманным. На сайте W3C висело следующее заявление: «Этот документ был в числе разрабатываемых рекомендаций W3C, но работа по спецификации была остановлена. Спецификация зашла в тупик: все заинтересованные разработчики использовали одинаковый SQL-backend (Sqlite), но нам нужно несколько независимых реализаций для продолжения спецификации.» [69]. Таким образом, связанные с SQL-инъекциями угрозы, которые могли затронуть Web 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С-Битрикс: Управление сайтом”
piratesccru track2shopcc

Author: wpadmin