Архив метки: PositiveTechnologies

Средства Детектирования Уязвимостей Кода (СДУК)

Добавить комментарий

Средства Детектирования Уязвимостей Кода (СДУК).

4. Средства Детектирования Уязвимостей Кода (СДУК)

Позволяют детектировать неизвестные уязвимости (например XSS в самописном веб-приложении или переполнение буфера с перезаписью адреса возврата в серверном/десктопном приложении) и известные уязвимости CVE/БДУ на основе анализа исходного кода. Анализ, как правило, статический и проводится в рамках жизненного цикл разработки ПО (SDLC).

Positive Technologies - PT Application Inspector. Инструмент для выявления уязвимостей и тестирования безопасности приложений. Позволяет проводить статический анализ приложений (SAST) с технологией абстрактной интерпретации. Также поддерживает и другие технологии анализа: динамический (DAST), интерактивный (IAST), анализ сторонних компонентов (SCA).

Ростелеком Солар - Solar appScreener. Комплексное решение для контроля безопасности ПО c применением статического (SAST) и динамического (DAST) анализа кода. Решение обладает широкими возможностями по интеграции с репозиториями, системами отслеживания ошибок, интегрированными средами разработки и сервисами CI/CD.

НПО «Эшелон» - AK-VS 3. Инструмент для выявления дефектов кода и уязвимостей в ПО. Позволяет проводить статический анализ (SAST) кода приложений. Также поддерживает и другие технологии анализа: динамический (DAST), интерактивный (IAST), автоматизированный контроль полноты и избыточности ресурсов проекта. В состав AK-VS 3 входит модуль автоматизированного построения векторов атак.

PVS-Studio. Решение для статического анализа кода (SAST). Поддерживает языки C, C++, C# и Java. Позволяет детектировать ошибки и дефекты безопасности на основе рекомендаций CWE, OWASP Top 10 и SEI CERT Coding Standards. Также позволяет выполнять композиционный анализ кода (SCA) для C# проектов.

Стингрей. Платформа для автоматизированного анализа защищённости мобильных приложений (iOS, Android). Позволяет проводить статический анализ приложений (SAST). Также поддерживает и другие технологии анализа: динамический (DAST), интерактивный (IAST), анализ программных интерфейсов (API ST). Позволяет интегрировать в DevOps поиск, анализ дефектов и проверку соответствия стандартам для каждой сборки приложения.

Profiscope - CodeScoring. Решение для композиционного анализа исходного кода, обеспечивает защиту цепочки поставки ПО. Позволяет выявлять зависимости от Open Source и генерировать реестр компонентных связей (SBoM). Детектирует известные уязвимости по базам NVD NIST, GitHub Advisories и т.п. Обеспечивает режим защиты для прокси-репозиториев (функция OSA). Позволяет интегрироваться с основными известными репозиториями кода: GitHub, GitLab, BitBucket и Azure DevOps.

Картинка "Средства Детектирования Уязвимостей Приложений (СДУП)" в рамках проекта карты российских около-VM-ных вендоров

Добавить комментарий

Картинка Средства Детектирования Уязвимостей Приложений (СДУП) в рамках проекта карты российских около-VM-ных вендоров

Картинка "Средства Детектирования Уязвимостей Приложений (СДУП)" в рамках проекта карты российских около-VM-ных вендоров.

Это у нас примерно соответствует DAST-ам.

Традиционный disclaimer: Характеристику не нужно воспринимать как описание всех особенностей и возможностей продукта! Тем более не стоит сравнивать продукты между собой только на основе этой характеристики. Характеристика должна показывать почему вендор попал в категорию.

Если какого-то вендора забыл в этой категории или есть вопросы по характеристикам, пишите в личку - обсудим, добавлю/поправлю. Ну или поясню почему получилось так, а не иначе. 🙂

Предыдущие картинки
- СДУИ (Инфраструктуры), обновленная, добавил Cloud Advisor
- СДУСП (Сетевого Периметра), обновленная, добавил сервис от МТС RED

Средства Детектирования Уязвимостей Приложений (СДУП)

Добавить комментарий

Средства Детектирования Уязвимостей Приложений (СДУП).

3. Средства Детектирования Уязвимостей Приложений (СДУП)

Позволяют детектировать неизвестные уязвимости в приложениях (например XSS в самописном веб-приложении или переполнение буфера с перезаписью адреса возврата в серверном/десктопном приложении). Приложения включают в себя веб-приложения, программные интерфейсы (API), десктопные и серверные приложения, приложения для мобильных устройств (Android, iOS, Аврора). Анализ, как правило, динамический без доступа к исходному коду.

Positive Technologies - PT BlackBox, PT Application Inspector. PT BlackBox - сканер безопасности приложений, работающий методом черного ящика. Использует динамический анализ приложений (комбинация сигнатурного и эвристического анализа). Доступ к базовой облачной версии PT BlackBox Scanner предоставляется бесплатно. Расширенная версия PT BlackBox является On-Premise продуктом. PT Application Inspector - инструмент для выявления уязвимостей и тестирования безопасности приложений. Позволяет проводить динамический анализ приложений (DAST) для проверки результатов статического анализа (SAST). Также поддерживает и другие технологии анализа: интерактивный (IAST), анализ сторонних компонентов (SCA).

Ростелеком Солар - Solar appScreener. Комплексное решение для контроля безопасности ПО c применением динамического (DAST) и статического (SAST) анализа кода. Решение обладает широкими возможностями по интеграции с репозиториями, системами отслеживания ошибок, интегрированными средами разработки и сервисами CI/CD.

НПО «Эшелон» - AK-VS 3. Инструмент для выявления дефектов кода и уязвимостей в ПО. Позволяет проводить динамический анализ (DAST) приложений. Также поддерживает и другие технологии анализа: статический (SAST), интерактивный (IAST), автоматизированный контроль полноты и избыточности ресурсов проекта. В состав AK-VS 3 входит модуль автоматизированного построения векторов атак.

ИСП РАН - ИСП Crusher, Natch, Блесна. ИСП РАН предлагает широкий набор технологий для анализа десктопных и серверных приложений, а также решений на основе этих технологий. ИСП Crusher - программный комплекс, комбинирующий несколько методов динамического анализа. Состоит из двух инструментов: ИСП Fuzzer для проведения фаззинг-тестирования и Sydr, отвечающий за автоматическую генерацию тестов для сложных программных систем. Фаззинг осуществляется с использованием исходных кодов в режиме "серого ящика". Решения Natch и Блесна базируются на технологии полносистемной эмуляции и интроспекции виртуальных машин. Natch - инструмент для определения поверхности атаки: исполняемых файлов, динамических библиотек, а также функций, отвечающих за обработку входных данных. Использует технологии анализа помеченных данных, интроспекции виртуальных машин и детерминированного воспроизведения. Блесна - специализированный инструмент, предназначенный для поиска утечек в памяти чувствительных данных, таких как пользовательские пароли и ключи шифрования.

Стингрей. Платформа для автоматизированного анализа защищённости мобильных приложений (iOS, Android). Позволяет проводить динамический анализ приложений (DAST). Также поддерживает и другие технологии анализа: статический (SAST), интерактивный (IAST), анализ программных интерфейсов (API ST). Позволяет интегрировать в DevOps поиск, анализ дефектов и проверку соответствия стандартам для каждой сборки приложения.

CIS OVAL Repository съехал на GitHub

1 комментарий

CIS OVAL Repository съехал на GitHub. Обнаружил, что в феврале этого года CIS настроили редирект с oval.cisecurity.org на github.com/CISecurity/OVALRepo. И это так себе новость, т.к. похоже проект окончательно загнулся и CIS утратили к нему интерес. По случаю хочется сделать небольшой экскурс в историю.

Начиная с 2005 года, развитием OVAL (Open Vulnerability and Assessment Language) занималась корпорация MITRE. Как артефакт тех времен остался сайт https://oval.mitre.org/. Там была подробная адекватная документация. Был открытый интерпретатор для OVAL (OVALdi). Был реестр совместимых продуктов. Одним из этих совместимых продуктов там значится сторонний OVAL репозиторий Positive Technologies (ныне не работает, можно в архиве глянуть), я приложил к нему руку. 😉 Ещё прикольная строчка это ALTX-SOFT RedCheck как OVAL-ный сканер.

Ещё там был центральный репозиторий, в который можно было контрибьютить OVAL контент. А компаниям, которые больше всех этим занимались, давали Top Contributor Award. Можно посмотреть, что с 2012 года до 2015 года топовым контрибьютором был наш отечественный ALTX-SOFT.

В 2015 в MITRE что-то произошло. Видимо что-то связанное с финансированием. Всю эту OVAL-ную тему начали резко сворачивать. Разработчики разбежались. Сам стандарт ушел в NIST и кое-как поддерживается теперь в рамках SCAP. А центральный репозиторий отдали в CIS (Center for Internet Security). Веб-репозиторий кое-как повторили. Но на этом всё и закончилось. Какого-то развития от CIS больше не было. Даже Top Contributor Award не восстановили. И вот сейчас даже веб-страницы OVAL Repostory убрали с сайта CIS, сделали редирект на GitHub. И на сайте CIS-а упоминания проекта OVAL Repostory больше нет. 🤷‍♂️

А в самом репозитории на GitHub практически нет свежих коммитов. Какие-то коммиты есть только по дефинишенам для уязвимостей. Но, например, более-менее массово уязвимости Windows добавляли последний раз в июне прошлого года.

Почему загнулся центральный репозиторий OVAL контента MITRE/CIS?

1. Пока проект был в MITRE он был достаточно живой. Очевидно потому, что были люди, которые работали над ним на фулл-тайм за гос. финансирование. Как минимум, они неплохо драйвили работу с комьюнити, минутки встреч OVAL Board было интересно почитать.
2. CIS в принципе были мало заинтересованы в этом проекте. Основное у них это CIS Benchmarks и CIS Controls. Да, они используют OVAL-контент для проверок конфигураций Windows хостов в CIS CAT, но и только.
3. Vulnerability Management вендоры не заинтересованы контрибьютить свои детекты уязвимостей. Даже если они у них есть в виде OVAL. Да, для части вендоров интересно было получать Top Contributor Award и использовать это в маркетинге. Но и они в основном контрибьютили не детекты уязвимостей, а детекты установки софтов. Зачем отдавать в открытый доступ то, что могут использовать другие VM-вендоры?
4. Вендоры ОС теоретически могли бы отдавать свой OVAL-контент, но их к этому не обязывали. А генерить полностью свой контент проще чем реюзать существующие объекты в общем репозитории: убирать дубли, разрешать конфликты в описании и т.п. Да и вендоры ОС без внешней стимуляции не особо стремились поддерживать OVAL контент. Взять Microsoft. Когда была программа FDCC/USGCB по контролю инфраструктуры федеральных агентств, они выпускали свой OVAL/SCAP контент. А как только программа прекратилась, перестали.

Так что если наши регуляторы захотят повторить что-то подобное, лучше сразу продумать мотивацию всех участников. 😉

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies

2 комментария

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies. Статья вышла в BIS Journal 22 февраля, но я только сейчас её увидел. Мне в целом, импонирует подход PT к VM процессу. Особенно то, что Евгений Полян и Анастасия Зуева транслируют в своих выступлениях. Поэтому мимо их совместной статьи пройти никак не мог. Собрал краткую выжимку, за деталями рекомендую обратиться к исходной статье.

1. ИТ и ИБ должны дружить и вместе работать над исправлением уязвимостей, иначе ничего не получится.

2. Если не исправлять уязвимости, это может привести к серьезным инцидентам и недопустимым событиям для бизнеса.

3. Разрабатываете/внедряете новую систему? Проверьте, что в ТЗ учтены:
3.1. Технологические окна для регулярных обновлений
3.2. Возможность сканирования (от меня: лучше даже шире - проверить, что есть средство детектирования уязвимостей для системы)
3.3. План реагирования на появление новых опасных уязвимостей для ИТ и ИБ

4. Пока не убрали уязвимости, новую систему в промышленную эксплуатацию не берем. Как взяли - продолжаем поддерживать уровень безопасности.

5. Три шага к организации процесса управления уязвимостями:
5.1. Определить перечень недопустимых для организации событий c бизнесом и ТОПами
5.2. Определить риск-рейтинг активов
5.3. Составить регламент работы и обслуживания каждого типа активов, согласовать с бизнесом и IT

6. Зафиксируйте роли подразделений:
6.1. Руководство компании - приоритеты и перечень недопустимых событий
6.2. Топ-менеджмент - перечень наиболее важных сервисов
6.3. ИТ-подразделение - обновление в соответствии с SLA
6.4. ИБ-подразделение - приоритеты устранения уязвимостей, критерии эффективности процессов ИБ, контроль уровня защищенности, определение ключевых активов

7. Определение сроков обновления систем и регламента обновлений:
7.1. Выделить ключевые активы (контроллеры домена, серверы Exchange, системы управления виртуализацией, рабочие станции администраторов и т.д.)
7.2. Установить регламенты по обновлению, определить SLA (и что делать если SLA будет нарушаться)
7.3. Для зарубежного ПО использовать алгоритм НКЦКИ и результаты тестирования обновлений ПО от ФСТЭК

Что мне нравится в этой статье: большой акцент на регулярных обновлениях. Ситуация когда месяцами-годами системы не патчатся и все ждут ИБ-шников, которые должны просканить и поставить задачу на обновление - это не норма. IT-шник, если есть обновление безопасности - иди ставь! ИБшник (VM-щик) нужен для того, чтобы удостовериться, что все хорошо и по регламенту работает, а не для того, чтобы всех пушить постоянно. Ну и для того, чтобы бить в рынду, когда появляется что-то реально критичное.

Что не особо нравится: "три шага" к организации процесса управления уязвимостями это, конечно, что-то из серии научной фантастики. Просто прекрасно, если где-то это действительно без оговорок запустилось, но это скорее не рекомендация к команде ИБ, а реклама крутого консалтинга, который такие штуки делать умеет. Про планирование новых проектов с требованиями по VM тоже все правильно, но отстаивать эти требования также будет ох как не просто. Наиболее практически полезной кажется идея, что наводить порядок нужно с ключевых активов и разгребаться дальше насколько ресурсов хватит.

Про карту рынка Импортозамещение 2023 от CNews

1 комментарий

Про карту рынка Импортозамещение 2023 от CNewsПро карту рынка Импортозамещение 2023 от CNews

Про карту рынка Импортозамещение 2023 от CNews. Это что-то феерическое. "Производители самых известных российских аппаратных и программных ИТ-продуктов, предлагаемых для замены зарубежных решений в наиболее важных сегментах." Интерес у меня был прежде всего к разделу "Корпоративное программное обеспечение -> Информационная безопасность".

То, что Vulnerability Management-у, и даже в целом анализу защищенности, место не нашлось это ещё ладно. Допустим место нашей темы где-то в аналитике. Но то, что Positive Technologies вообще нигде не упомянули, включая раздел SIEM, это просто смешно. 😀 Получается ИскраУралТЕЛ (без негатива, просто как пример) входит в список самых известных российских ИБ вендоров, а PT нет. 😅

Positive Technologies открыли прием заявок на стажировку для студентов ИБ-шников третьего курса или старше

1 комментарий

Positive Technologies открыли прием заявок на стажировку для студентов ИБ-шников третьего курса или старше. Заявки принимаются до 27 февраля, а занятия начнутся 6 марта.

1 этап. Лабораторки, знакомство с продуктами компании. 1,5 месяца.
2 этап. Интенсивы по специализациям. 3 недели.
3 этап. Оплачиваемая стажировка в подразделениях компании для лучших студентов. До конца июня.

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

Что я об этом думаю.

Первое место работы/стажировки это очень важно. Зачастую это закладывает дальнейший вектор развития. Если бы я сразу после Бауманки не попал в Positive Technologies в команду разработки базы знаний MaxPatrol 8, то и никакого "Управления Уязвимостями" в моей жизни не было бы. А так получилась прикольная рабочая история длиною 6,5 лет и хорошая база на будущее. Очень благодарен PT за это. 😇

Насколько могу судить, у многих так. Кто с чего стартовал, тот на том в итоге и специализировался. Те, кто по каким-то причинам начали путь не в ИБ (в IT-администрировании, программировании, QA и т.д.), как правило, ИБ-шниками не стали. И не скажу, что это плохо. Но, имея ИБшный диплом, не использовать его в качестве конкурентного преимущества на рынке труда довольно странно. Особенно на фоне того с каким трудом в ИБ пытаются пробиться люди без профильного образования.

Советую тем, кто будет принимать участие в стажировке в PT (да и в любом ИБ-вендоре), с самого начала присмотреться что в компании есть интересного лично для вас, чем вам хотелось бы заниматься, какие знания у вас уже есть для этого, какие знания вам нужно для этого получить. Если вы в этом сами для себя разберетесь и начнете это как-то артикулировать, то уже будете сильно выделяться на общем фоне тех, кто "может копать, может не копать".

У студентов часто есть такой взгляд "хочу в offensive, хочу в pentest" или "хочу в SOC, хочу злодеев ловить". Да, темы модные и в PT это есть. И пентесты, и разнообразный ресерч, и SOC. Но ещё есть и очень крутые команды разработки: Vulnerability Management (и куча направлений по поддерживаемым системам внутри), SIEM, SAST/DAST/IAST, WAF, NGFW, XDR и т.д. Если туда попадете, то будете в деталях понимать как эти штуки работают изнутри. Это уникальный востребованный опыт, который нигде как ИБ-вендоре не получишь.

Кроме того, нужно понимать что ситуация с ИБ продуктами в РФ стремительно меняется. Ещё лет 5 назад было достаточно справедливо сказать, что российские ИБ решения это для госов и около-госов, а все остальные используют зарубежные решения. Теперь идет массовый переход на продукты отечественных ИБ-вендоров (в том числе PT). И тут вы с опытом не только эксплуатации продукта, но и глубокими знаниями как продукт изнутри работает ("Использовал? Ха, да я его сам разрабатывал!"). Смекаете перспективы? 😉

В общем, если вы студент, подумайте над программой стажировки в PT. Если у вас есть знакомые студенты ИБ-шники, перешлите это им.