Спускаем MAYHEM на двоичный код(часть 3) 101 201 dumps, legit cvv sites 2021

В данном документе мы представляем MAYHEM, новую систему для автоматического поиска эксплуатируемых багов в двоичных файлах программ.
MAYHEM состоит из приблизительно 27 тысяч строк кода на C/C++ и OCaml. Наш фреймворк двоичного инструментирования построен на основе Pin [18], а все перехватчики моделируемой системы и API-вызовы написаны на C/C++. Движок символического выполнения написан целиком на OCaml и состоит из 10000 строк кода. Мы используем BAP [15] для преобразования ассемблерных инструкций в ПЯ. Мы используем Z3 [12] в качестве процедуры принятия решений, для которой мы построили прямые связки с OCalm. Чтобы сделать возможным удаленный обмен информацией между двумя данными компонентами, мы создали нашу собственную кроссплатформенную легковесную реализацию RPC-протокола (на C++ и OCalm). Кроме того, в целях сравнения мы реализовали все три режима символического выполнения: онлайновый, оффлайновый и гибридный.
Мы оценивали нашу систему на двух виртуальных машинах, запущенных на настольном компьютере с процессором 3.40GHz Intel(R) Core i7-2600 и 16 ГБ оперативной памяти. Каждая ВМ имела 4ГБ памяти. На машинах были установлены Debian Linux (Squeeze) VM и Windows XP SP3.
Мы загрузили 29 различных уязвимых программ, чтобы проверить эффективность MAYHEM. Таблица I обобщает наши результаты. Эксперименты проводились на немодифицированных, лишенных отладочной информации двоичных файлах как под Linux, так и под Windows. Одно из Windows-приложений (Dizzy) являлось упакованным.
Столбец 3 показывает тип эксплоита, обнаруженный MAYHEM, один из описанных в §VI. Столбец 4 показывает источники символических данных, которые мы рассматривали для каждой из программ. Здесь представлены примеры всех типов источников символических входных данных, которые поддерживает MAYHEM, включая аргументы командной строки (Arg.), переменные окружения (Env. Vars), сетевые пакеты (Network) и символические файлы (Files). Столбец 5 – это размер символического источника. Столбец 6 описывает предусловия, которые мы предоставили MAYHEM для каждой из 29 программ. Они делятся на три категории: длина, префикс и данные, приводящие к аварийному завершению, как описано в §IV-D. Столбец 7 показывает консультативное заключение для всех продемонстрированных эксплоитов. MAYHEM смог найти две уязвимости нулевого дня в двух Linux-приложениях, о которых мы сообщили разработчикам.
Последний столбец показывает время генерации эксплоита для проанализированных MAYHEM программ. Мы измеряли время генерации эксплоита как промежуток от начала анализа до создания первого рабочего эксплоита. Требуемое время сильно разнилось в зависимости от сложности приложения и размера символических входных данных. Быстрее всего (1.9 секунды) эксплоит нашелся для утилиты конфигурации беспроводных сетей в Linux, iwconfig, а больше всего времени (около 4 часов) ушло на поиск эксплоита для Windows-программы Dizzy.
Мы измерили эффективность гибридного символического выполнения по двум шкалам: использование памяти и скорость.
Требует меньше памяти, чем онлайновое выполнение. Рисунок 7 показывает среднее использование памяти MAYHEM за время анализа утилиты echo из coreutils в ходе онлайнового, оффлайнового и гибридного выполнений. После нескольких минут онлайновое выполнение достигает максимального количества действующих интерпретаторов и начинает прерывать пути выполнения. В данной точке память увеличивается линейно, поскольку исследуемые пути становятся глубже. Отметим, что в начале гибридное выполнение потребляет столько же памяти, что и онлайновое, не превосходя установленного порога, но использует ресурсы памяти более агрессивно, чем оффлайновое выполнение на всем протяжении работы. Оффлайновое выполнение требует гораздо меньшего количества памяти (в среднем менее 500КБ), но ценой более низкой производительности, что продемонстрировано ниже.
Быстрее, чем оффлайновое выполнение. Рисунок 8 показывает время исследования путей для утилиты /bin/echo при различных ограничениях на максимальное количество действующих выполнителей. В данном эксперименте мы использовали 6 байтов символических аргументов для исследования всего пространства входных данных за разумное время. Когда максимальное количество действующих выполнителей равно 1, MAYHEM сохранял на диск контрольные точки – средний размер которых 30 КБ – для каждой символической ветви, что эквивалентно оффлайновому исполнению. Когда максимальное количество действующих выполнителей равнялось 128 или больше, MAYHEM не нужно было создавать контрольные точки, что эквивалентно онлайновому выполнению. В результате онлайновое выполнение заняло 25 секунд, тогда как оффлайновому понадобилось 1400. В рамках данного эксперимента онлайновое выполнение оказалось в 56 раз быстрее, чем оффлайновое. Мы выделили две основных причины такого улучшения производительности.
Во-первых, издержки повторного выполнения больше, чем издержки переключения между контекстами двух состояний выполнения (§IV-B). В оффлайновой схеме MAYHEM тратит более 25% времени на повторное выполнение предыдущих путей. В онлайновом случае на переключение контекста было потрачено всего 2% времени. Во-вторых, в нашей реализации онлайновое выполнение является более эффективным относительно кэширования. В частности, онлайновое выполнение более эффективно использует кодовый кэш Pin [18] путем переключения между путями в памяти в ходе одного выполнения. В результате кодовый кэш делает онлайновое выполнение в 40 раз быстрее, чем оффлайновое.
Кроме того, мы запускали Windows-программу с графическим интерфейсом (MiniShare), чтобы сравнить производительность между оффлайновым и гибридным выполнением. Мы выбрали эту программу, поскольку она не требует взаимодействия с пользователем (например, кликов мышью), чтобы запустить символическое выполнение. Мы выполняли данную программу в течение часа для каждого режима выполнения. Гибридное выполнение оказалось в 10 раз быстрее, чем оффлайновое.
Как уже говорилось в §V, индексное моделирование памяти позволяет MAYHEM делать заключения о символических индексах. Результаты наших экспериментов из таблицы I показывают, что более 40% программ требуют моделирования символической памяти (столбец 6) для нахождения уязвимости. Другими словами, после нескольких часов анализа MAYHEM не мог генерировать эксплоиты для этих программ без индексного моделирования памяти. Чтобы понять причину этого, мы исследовали наши оптимизации индексного моделирования памяти на сервере atphttpd.
Разрешение границ. Таблица II показывает время, требуемое MAYHEM для нахождения уязвимости в atphttpd при разных уровнях оптимизации алгоритма разрешения границ. Время включает обнаружение эксплоита, но не включает его генерацию (поскольку алгоритм разрешения границ не оказывает на нее влияния). Строка 3 показывает, что VSA уменьшает среднее количество запросов к SMT-решателю на одно обращение к символической памяти с 54 до 14 и сокращает затраченное время на 75%.
Строка 4 показывает количество запросов, когда помимо VSA включен кэш уточнений (R-кэш). R-кэш уменьшает количество необходимых двоичных поисков с 4003 до 7, давая 57-процентный прирост скорости. Последняя строка показывает влияние кэша лемм (L-кэша), включенного поверх других оптимизаций. L-кэш берет на себя большую часть нагрузки R-кэша, что приводит к 59% ускорению. Мы не ожидаем, что L-кэш всегда будет столь эффективен, поскольку он сильно зависит от независимости формул в предикате пути. Общий прирост скорости составил 96%.
Представление дерева индексного поиска (IST). Как было упомянуто в §V-B, MAYHEM моделирует загрузки из символической памяти в виде IST. Чтобы показать эффективность этой оптимизации, мы запустили atphttpd с тремя различными представлениями формул (показано в таблице III). Сбалансированный IST оказался более чем в 4 раза быстрее, чем несбалансированное представление двоичного дерева, а с линеаризацией формул мы получили общее девятикратное ускорение. Отметим, что при использовании символических массивов (без IST) мы не смогли обнаружить эксплоит в рамках временных ограничений.
Чтобы оценить способность MAYHEM охватывать новые пути, мы загрузили символический выполнитель с открытым кодом (KLEE) и сравнили его производительность с MAYHEM. Отметим, что KLEE работает с исходными кодами, а MAYHEM с двоичными.
Мы измеряли покрытие кода 25 приложений из набора coreutils как функцию от времени. MAYHEM запускался для каждого из этих приложений не более, чем на час. Мы использовали сгенерированные тест-кейсы для измерения покрытия кода с помощь утилиты gcov. Результаты показаны на рисунке 9.
Мы использовали 21 утилиту с наименьшим размером кода и еще 4 выбранных нами утилиты большего размера. MAYHEM достиг среднего покрытия 97.56% на приложение и получил 100% покрытие для 13 утилит. Для сравнения KLEE достиг 100% покрытия на 12 утилитах без симулирования сбоев системных вызовов (чтобы иметь одинаковую с MAYHEM конфигурацию). Таким образом, MAYHEM кажется способным конкурировать с KLEE на данном наборе данных. Отметим, что MAYHEM не разработан специально для максимизации покрытия кода. Однако, наши эксперименты позволяют выполнить черновое сравнение с другими символическими выполнителями.
Мы отобрали 8 различных программ из рабочих образцов AEG [2] и запустили оба инструмента для сравнения времени генерации эксплоита для каждой из этих программ, используя одинаковую конфигурацию (Таблица IV). MAYHEM оказался в среднем в 3.4 раза медленнее AEG. AEG использует исходный код, а значит имеет преимущество работы на более высоком уровне абстракции. На двоичном уровне нет типов и высокоуровневых структур вроде функций, переменных, буферов и объектов. Количество исполняемых инструкций (таблица IV) – другой фактор, подчеркивающий разницу между анализом исходного кода и чисто двоичным анализом. Учитывая это, мы полагаем, что данный результат является положительным и показывает конкурентноспособность MAYHEM.
Размер предусловия. В качестве дополнительного эксперимента мы измеряли, как наличие предусловия влияет на время генерации эксплоита. Мы отобрали 6 программ, которым для нахождения эксплуатируемого бага нужны входные данные, приводящие к аварийному завершению, и стали итеративно уменьшать размер предусловия и измерять время генерации эксплоита. Рисунок 10 обобщает наши результаты в терминах нормализованного размера предусловия – например, нормализованное предусловие размером 70% для 100-байтных данных, приводящих к аварийному завершению, означает, что мы предоставляем MAYHEM 70 байтов данных в качестве предусловия. Хотя поведение кажется зависящим от программы, в большинстве программ мы наблюдали внезапный фазовый переход, когда удаление одного символа могло привести к тому, что MAYHEM переставал обнаруживать эксплуатируемый баг за установленное время. Мы полагаем, что это интересная тема для дальнейших работ в данной области.
Оптимизация формул. Как говорилось в разделе §IV-E, MAYHEM использует различные методы оптимизации для ускорения запросов к решателю. Для сравнения оптимизированной версии с обычной, мы выключали некоторые или все оптимизации.
Мы выбрали 15 Linux-программ для оценки ускорения, получаемого при включении различных уровней оптимизации. Рисунок 11 показывает непосредственное сравнение (по количеству найденных эксплоитов и времени их генерации) четырех опций оптимизации формул. Алгебраические упрощения, как правило, ускоряли наш анализ и показали 10% ускорение для 15 тестовых программ. Значительное ускорение имеет место, когда включена оптимизация разбиения на независимые формулы вместе с упрощениями, что дает ускорение в 10-100 раз.
Z3 поддерживает инкрементальное решение, поэтому в качестве дополнительного эксперимента мы измерили время генерации эксплоита в инкрементальном режиме Z3. В большинстве случаев время решения для инкрементальных формул сравнимо с временем, которое мы получали для оптимизации разбиения на независимые формулы. По существу, для половины наших образцов (7 из 15) инкрементальные формулы превзошли независимые формулы. В отличие от предыдущих результатов из этого следует, что использование решателя в инкрементальном режиме может убрать необходимость во многих упрощениях и оптимизациях формул. Недостатком использования решателя в инкрементальном режиме было то, что это делало состояние символического выполнения изменчивым, то есть снижало эффективность использования памяти в длинных тестах.
Тентированные инструкции. MAYHEM символически выполняет только блоки тентированных инструкций – все прочие блоки выполняются нативно. Рисунок 12 показывает процент тентированных инструкций для 24 программ (взятых из таблицы I). Более чем 95% инструкций в наших образцах не были тентированы, и данная оптимизация давала приблизительно восьмикратное ускорение.
Большая часть данной работы сосредоточена на поиске эксплуатируемых багов. Однако, мы полагаем, что основные рассмотренные методы могут быть адаптированы к другим доменам приложений в контексте символического выполнения. Мы также полагаем, что наше гибридное символическое выполнение и индексное моделирование памяти являются новыми принципами архитектуры символического выполнения.
Мы подчеркиваем, что назначение MAYHEM – информирование пользователя о существовании эксплуатируемых багов. Производимые им эксплоиты предназначены для демонстрации серьезности проблемы и для помощи в отладке и исправлении соответствующих недостатков. MAYHEM не пытается обойти защитные механизмы ОС вроде ASLR или DEP, которые вероятно защитят системы от генерируемых нами эксплоитов. Однако, наша предыдущая работа над Q [25] показывает, что сломанный эксплоит (который перестал работать из-за ASLR или DEP) может быть автоматически трансформирован – с высокой вероятностью – в эксплоит, который обходит оба упомянутых средства защиты современных ОС. Хотя мы могли бы передавать сгенерированные MAYHEM эксплоиты напрямую в Q, в данной работе мы не исследовали эту возможность.
Ограничения. У MAYHEM есть модели не для каждого из системных/библиотечных вызовов. Текущая реализация моделирует около 30 системных вызовов в Linux и 12 библиотечных вызовов в Windows. Для анализа больших и более сложных программ необходимо моделировать большее количество системных вызовов. Это следствие символического выполнения на уровне процесса. Символические выполнители целых систем вроде S2E [28] или BitBlaze [5] могут выполнять код как пользователя, так и ядра, и, таким образом, не имеют данного ограничения. Недостаток таких систем в том, что анализ целой системы может быть гораздо более затратным из-за большей стоимости восстановления состояния и времени, тратящегося на анализ кода ядра. Другое ограничение состоит в том, что MAYHEM может анализировать лишь один поток выполнения при каждом запуске. MAYHEM не может обрабатывать многопоточные программы, в которых потоки взаимодействуют друг с другом (через передачу сообщений или разделяемую память). Наконец, MAYHEM выполняет только тентированные инструкции, а потому обладает теми же недостатками, что и taint-анализ, включая недотентирование, перетентирование и неявные потоки [24].
Дальнейшая работа. Наши эксперименты показывают, что MAYHEM может генерировать эксплоиты для стандартных уязвимостей вроде переполнений буфера в стеке, использования объектов после освобождения и атак, раскрывающих информацию. На высоком уровне подобные атаки возможно обнаружить с помощью свойств безопасности, подобных тем, что сейчас использует MAYHEM. Однако, по прежнему открытым остается вопрос, как те же методы могут масштабироваться и обнаруживать подобные эксплоиты в более объемных программах.
Brumley и пр. [7] представили автоматическую генерацию эксплоитов на основе патчей (APEG). APEG использует патч для выяснения нахождения бага и затем использует расщепление для построения формул путей выполнения кода от источника входных данных до уязвимой строки. MAYHEM находит уязвимости и сами уязвимые пути кода. Кроме того, понятия эксплоита для APEG является более абстрактным: любые входные данные, которые нарушают проверки, вводимые путем выполнения, считаются эксплоитами. Здесь мы рассматриваем именно эксплоиты, перехватывающие поток управления, которые не генерируются APEG автоматически.
Heelan [14] первым описал метод, который принимает на вход входные данные, приводящие к аварийному завершению программы, вместе с регистром перехода и автоматически генерирует эксплоит. Наше исследование исследует пространство состояний для поиска таких входных данных.
AEG [2] была первой системой, которая решала как проблему обнаружения эксплуатируемых багов, так и автоматичесую генерацию эксплоитов. AEG работает только с исходным кодом и вводит предусловное символическое выполнение как способ сфокусировать символическое выполнение на определенной части пространства поиска.. MAYHEM является логичным расширением AEG на двоичный код. На практике работа с бинарным кодом открывает возможность генерации эксплоитов для более широкого класса программ и сценариев.
Существуют фреймворки исключительно двоичного символического выполнения, например, Bouncer [10], BitFuzz [8], BitTurner [6] FuzzBall [20], McVeto [27], SAGE [13], и S2E [28], которые использовались в разнообразных доменах приложений. При создании MAYHEM мы главным образом решали вопрос расширения двоичного символического выполнения для поиска и демонстрации эксплуатируемых багов. Гибридное символическое выполнение, представленное в данном документе, полностью отличается от гибридного консимволического тестирования [19], которое чередует случайное тестирование с консимволическим выполнением для достижения лучшего покрытия кода.
Мы представили MAYHEM, инструмент для автоматического поиска эксплуатируемых багов в двоичных (т. е. исполняемых) программах эффективным и расширяемым способом. С этой целью в MAYHEM представлена новую схему гибридного символического выполнения, которая сочетает выгоды существующих методов символического выполнения (онлайнового и оффлайнового) в одной системе. Мы также представили метод индексного моделирования памяти, который позволяет MAYHEM обнаруживать на двоичном уровне большее количество эксплуатируемых багов. Мы использовали MAYHEM для анализа 29 приложений и автоматически обнаружили и продемонстрировали 29 эксплуатируемых уязвимостей.
Мы благодарим нашего руководителя, Кристиана Кадара и анонимных рецензентов за их полезные комментарии и обратную связь. Это исследование было поддержано грантом a DARPA, выданным CyLab в университете Carnegie Mellon (N11AP20005/D11AP00262), грантом NSF Career grant (CNS0953751), и частично DAAD19-02-1-0389 и W911NF-09-1-0273. Содержимое документа не обязательно отражает точку зрения или политику государства.
1 Здесь используется менее формальный, но более емкий термин “баг” вместо “программная ошибка”
2 Заметим, что термин “контрольная точка” отличается от “зерна” оффлайнового выполнения, которое является лишь конкретными входными данными.
Ссылки
[1] “Orzhttpd, a small and high performance http server,” http://code.google.com/p/orzhttpd/.
[2] T. Avgerinos, S. K. Cha, B. L. T. Hao, and D. Brumley, “AEG: Automatic exploit generation,” in Proc. of the Network and Distributed System Security Symposium, Feb. 2011.
[3] D. Babi´ c, L. Martignoni, S. McCamant, and D. Song, “Statically-Directed Dynamic Automated Test Generation,” in International Symposium on Software Testing and Analysis. New York, NY, USA: ACM Press, 2011, pp. 12–22.
[4] G. Balakrishnan and T. Reps, “Analyzing memory accesses in x86 executables.” in Proc. of the International Conference on Compiler Construction, 2004.
[5] “BitBlaze binary analysis project,” http://bitblaze.cs.berkeley.edu, 2007.
[6] BitTurner, “BitTurner,” http://www.bitturner.com.
[7] D. Brumley, P. Poosankam, D. Song, and J. Zheng, “Automatic patch-based exploit generation is possible: Techniques and implications,” in Proc. of the IEEE Symposium on Security and Privacy, May 2008.
[8] J. Caballero, P. Poosankam, S. McCamant, D. Babic, and D. Song, “Input generation via decomposition and re-stitching: Finding bugs in malware,” in Proc. of the ACM Conference on Computer and Communications Security, Chicago, IL, October 2010.
[9] C. Cadar, D. Dunbar, and D. Engler, “KLEE: Unassisted and automatic generation of high-coverage tests for complex systems programs,” in Proc. of the USENIX Symposium on Operating System Design and Implementation, Dec. 2008.
[10] M. Costa, M. Castro, L. Zhou, L. Zhang, and M. Peinado, “Bouncer: Securing software by blocking bad input,” in Symposium on Operating Systems Principles, Oct. 2007.
[11] J. R. Crandall and F. Chong, “Minos: Architectural support for software security through control data integrity,” in Proc. of the International Symposium on Microarchitecture, Dec. 2004.
[12] L. M. de Moura and N. Bjørner, “Z3: An efficient smt solver,” in TACAS, 2008, pp. 337–340.
[13] P. Godefroid, M. Levin, and D. Molnar, “Automated whitebox fuzz testing,” in Proc. of the Network and Distributed System Security Symposium, Feb. 2008.
[14] S. Heelan, “Automatic Generation of Control Flow Hijacking Exploits for Software Vulnerabilities,” Oxford University, Tech. Rep. MSc Thesis, 2002.
[15] I. Jager, T. Avgerinos, E. J. Schwartz, and D. Brumley, “BAP: A binary analysis platform,” in Proc. of the Conference on Computer Aided Verification, 2011.
[16] J. King, “Symbolic execution and program testing,” Commu- nications of the ACM, vol. 19, pp. 386–394, 1976.
[17] Launchpad, https://bugs.launchpad.net/ubuntu, open bugs in Ubuntu. Checked 03/04/12.
[18] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wallace, V. J. Reddi, and K. Hazelwood, “Pin: Building customized program analysis tools with dynamic instrumentation,” in Proc. of the ACM Conference on Programming Language Design and Implementation, Jun. 2005.
[19] R. Majumdar and K. Sen, “Hybrid concolic testing,” in Proc. of the ACM Conference on Software Engineering, 2007, pp. 416–426.
[20] L. Martignoni, S. McCamant, P. Poosankam, D. Song, and P. Maniatis, “Path-exploration lifting: Hi-fi tests for lo-fi emulators,” in Proc. of the International Conference on Architectural Support for Programming Languages and Operating Systems, London, UK, Mar. 2012.
[21] A. Moser, C. Kruegel, and E. Kirda, “Exploring multiple execution paths for malware analysis,” in Proc. of the IEEE Symposium on Security and Privacy, 2007.
[22] T. Newsham, “Format string attacks,” Guardent, Inc., Tech. Rep., 2000.
[23] J. Newsome and D. Song, “Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software,” in Proc. of the Network and Distributed System Security Symposium, Feb. 2005.
[24] E. J. Schwartz, T. Avgerinos, and D. Brumley, “All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask),” in Proc. of the IEEE Symposium on Security and Privacy, May 2010, pp. 317–331.
[25] E. J. Schwartz, T. Avgerinos, and D. Brumley, “Q: Exploit hardening made easy,” in Proc. of the USENIX Security Symposium, 2011.
[26] K. Sen, D. Marinov, and G. Agha, “CUTE: A concolic unit testing engine for C,” in Proc. of the ACM Symposium on the Foundations of Software Engineering, 2005.
[27] A. V. Thakur, J. Lim, A. Lal, A. Burton, E. Driscoll, M. Elder, T. Andersen, and T. W. Reps, “Directed proof generation for machine code,” in CAV, 2010, pp. 288–305.
[28] G. C. Vitaly Chipounov, Volodymyr Kuznetsov, “S2E: A platform for in-vivo multi-path analysis of software systems,” in Proc. of the International Conference on Architectural Support for Programming Languages and Operating Systems, 2011, pp. 265–278.
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания 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С-Битрикс: Управление сайтом”
101 201 dumps legit cvv sites 2021