Как и большинство DAST-решений, наш продукт эмулирует работу пентерстера. Продукт самостоятельно обходит сайт и находит все страницы и доступные точки атаки на них. Далее, используя «умный» анализатор, отсеивает дубли и повторы. Собрав точки атак, сканер начинает атаковать их генерируемым векторами, проводить пассивные проверки и проверки на версионые уязвимости. Все выше перечисленные действия делаются параллельно, а не последовательно. За счет этого достигается хорошая скорость сканирования. Полученные результаты группируются по типам уязвимостей и показываются пользователю. Вы можете посмотреть демо работы самостоятельно на bbs.ptsecurity.com
PT BlackBox изначально заточен под российский рынок. Продукт сканирует быстрее доступных конкурентов при том же уровне качества находимых уязвимостей, а также у него лучше широта охвата (в случае полного сканирования), глубина сканирования и детальные настройки (в on-premise варианте). А вообще рекомендуем записаться на пилот и попробовать самостоятельно.
Компании по ИБ предлагают утилиты для проверки ПК на угрозы, в том числе в прошивках.
Но если компьютер заражен, то угроза может быть скрыта от СЗИ и не будет обнаружена.
Эффективнее обнаруживать внедрение буткитов на стадии заражения, в том числе с использованием песочниц.
Стоит детально изучать такие активности, если они отличаются от типичных в инфраструктуре. На примере удаленного создания сервиса: такая активность, исходящая с сервера SCCM, для большинства инфраструктур является типичной. Запуск с рабочей станции пользователя уже более подозрительная активность. Конечно, есть еще много других факторов, таких как время активности или название сервиса, которые тоже влияют на решение о дальнейшем анализе.
Спасибо за интересный вопрос.
Зависит от того, что понимать под словом «ошибочны». Часть детектов из статьи указывают на активность, которая сама по себе является легитимным механизмом инфраструктуры Windows. Например, удаленное создание сервисов или создание пользователей. Это значит, что она может встречаться и при использовании администраторами. По опыту, легитимную активность можно достаточно быстро отсечь, обладая знаниями об инфраструктуре.
Другая часть детектов сделана на весьма конкретные вещи (например, reGeorg-туннель или активность Cobalt Strike), и они очень редко дают ошибочные срабатывания.
Добрый день. Artifactory сейчас у нас используется для различных целей. Основная — это хранилище бинарных артефактов от сборок компонент, из которых потом собираются инсталляторы продуктов.
Еще это хранилище релизных инсталляторов продуктов, которые прошли тестирование и готовы к распространению через корпоративные серверы обновлений GUS/FLUS.
Кроме того, мы используем artifactory как кеширующий прокси для внешних ресурсов — есть возможность подключить его для проксирования pypi, npm, rpm, nuget и других видов пакетов для пакетных менеджеров. Таким способом мы страхуем наши сборочные процессы от недоступности внешнего интернета или удаления пакетов из облачных хранилищ.
Автоматизацию внутри CI/CD-конвейера мы реализуем с помощью Python-библиотеки, поддерживаемой нами в опенсорсе: github.com/devopshq/artifactory
Отдельных статей по настройке и использованию artifactory мы пока не писали, так как он лишь один из элементов нашего комплексного CI/CD-конвейера — нет смысла рассматривать его отдельно, например, от CI-системы GitLab CI, хранилища кода GitLab или серверов доставки обновлений GUS/FLUS.
Добрый день. Да, вдумчиво не копали. Обнаружили в отладочных строках упоминание о DFU, и им воспользовались. Сама уязвимость, позволяющая вычитывать хоть часть кода, помогает понять, с каким функционалом имеешь дело.
В ходе этой атаки был получен доступ к серверу SCADA, с которого впоследствии на ПЛК были отправлены команды
какая SCADA… какой ПЛК ????
SCADA и ПЛК известных вендоров
по протоколу SLMP передаются штатные и легитимные команды на ПЛК
то есть это проблема протокола SLMP?
когда вы уже хотя бы за OPC UA возьметесь? или какую-нибудь проприетарную хрень типа Siemens, Omron, ABB, DELTA или Allen-Bradley?
Нет, это не проблема промышленного протокола. Это реализация одного из векторов при получении доступа к серверу SCADA – используя легитимные команды, произведено вмешательство в техпроцесс.
по протоколу SLMP передаются штатные и легитимные команды на ПЛК
то есть это проблема протокола SLMP?
когда вы уже хотя бы за OPC UA возьметесь? или какую-нибудь проприетарную хрень типа Siemens, Omron, ABB, DELTA или Allen-Bradley?
Взялись, следите за новостями :) OPC UA поддерживается в версии 3.3, Siemens S7Comm, S7+ поддерживаются с 2016 и 2018 годов соответственно. Два проприетарных протокола Emerson поддерживаются с 2018, а CIP в части открытой спецификации поддерживается с 2019 года.
Добрый день! Не совсем так :) В PT Application Inspector С/С++ поддерживается уже довольно давно. Кроме того, в продукте практически с момента его появления поддерживаются SAST, SCA, DAST и анализ конфигурационных файлов.
Инфраструктура КИИ в большей степени статична, нежели инфраструктура корпоративных сетей, и постоянных изменений в ней происходить не должно. Изменение в конфигурации сети — это часть жизненного цикла АСУТП и требует отражения в документации, а несанкционированные изменения требуют внимания со стороны инженера по ИБ.
При этом оператор может сам сформировать нужные ему белые списки, например, команд управляющего протокола, чтобы исключить пропуск несанкционированной команды на ПЛК. И белые списки- не единственный механизм в PT ISIM для выявления нарушений, экспертиза АСУ ТП, входящая в состав продукта, позволяет делать однозначные выводы про состояние защищённости объекта КИИ, не опираясь только на один инцидент.
В PT ISIM реализован механизм белых списков для различных объектов сети и видов их активности.
В начале работы, в режиме обучения, автоматически формируется белый список доверенных узлов и соединений, которые потом уточняются специалистами по ИБ. Все узлы и соединения не попавшие в белый список помечаются как неавторизованные и по ним заводятся соответствующие инциденты.
К сожалению, и на реальных объектах КИИ встречаются подобные грубые нарушения, недавний инцидент тому подтверждение. Справедливости ради надо сказать, что и до RDP на нашем мероприятии тоже надо было получить доступ, далеко не все команды нашли способ проникнуть в сегмент АСУ ТП.
Обо всем подробно мы рассказали на вебинаре. Его запись доступна здесь.
Но если компьютер заражен, то угроза может быть скрыта от СЗИ и не будет обнаружена.
Эффективнее обнаруживать внедрение буткитов на стадии заражения, в том числе с использованием песочниц.
Спасибо, поправили)))
Стоит детально изучать такие активности, если они отличаются от типичных в инфраструктуре. На примере удаленного создания сервиса: такая активность, исходящая с сервера SCCM, для большинства инфраструктур является типичной. Запуск с рабочей станции пользователя уже более подозрительная активность. Конечно, есть еще много других факторов, таких как время активности или название сервиса, которые тоже влияют на решение о дальнейшем анализе.
Зависит от того, что понимать под словом «ошибочны». Часть детектов из статьи указывают на активность, которая сама по себе является легитимным механизмом инфраструктуры Windows. Например, удаленное создание сервисов или создание пользователей. Это значит, что она может встречаться и при использовании администраторами. По опыту, легитимную активность можно достаточно быстро отсечь, обладая знаниями об инфраструктуре.
Другая часть детектов сделана на весьма конкретные вещи (например, reGeorg-туннель или активность Cobalt Strike), и они очень редко дают ошибочные срабатывания.
Имеется в виду валидный для сервера — проверяется домен, для которого выписан сертификат.
Еще это хранилище релизных инсталляторов продуктов, которые прошли тестирование и готовы к распространению через корпоративные серверы обновлений GUS/FLUS.
Кроме того, мы используем artifactory как кеширующий прокси для внешних ресурсов — есть возможность подключить его для проксирования pypi, npm, rpm, nuget и других видов пакетов для пакетных менеджеров. Таким способом мы страхуем наши сборочные процессы от недоступности внешнего интернета или удаления пакетов из облачных хранилищ.
Автоматизацию внутри CI/CD-конвейера мы реализуем с помощью Python-библиотеки, поддерживаемой нами в опенсорсе: github.com/devopshq/artifactory
Отдельных статей по настройке и использованию artifactory мы пока не писали, так как он лишь один из элементов нашего комплексного CI/CD-конвейера — нет смысла рассматривать его отдельно, например, от CI-системы GitLab CI, хранилища кода GitLab или серверов доставки обновлений GUS/FLUS.
Наш комплексный конвейер и процессы разработки упоминаются в более свежих статьях про Dev(Sec)Ops процессы. Посмотрите, возможно, что-то окажется полезным:
• Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps (2017)
• Моделирование производственных процессов в ИТ-компании (2018)
• Управление хаосом: наводим порядок с помощью технологической карты (2019)
• Личный опыт: как выстроить карьерный рост в отделе DevOps (2020)
• Как работает команда DevOps в Positive Technologies (2021)
• DevSecOps: как мы внедряли PT Application Inspector в наш продуктовый конвейер (2020)
• DevSecOps. PT Application Inspector в разработке ПО: блокировка релиза (2021)
SCADA и ПЛК известных вендоров
Нет, это не проблема промышленного протокола. Это реализация одного из векторов при получении доступа к серверу SCADA – используя легитимные команды, произведено вмешательство в техпроцесс.
Взялись, следите за новостями :) OPC UA поддерживается в версии 3.3, Siemens S7Comm, S7+ поддерживаются с 2016 и 2018 годов соответственно. Два проприетарных протокола Emerson поддерживаются с 2018, а CIP в части открытой спецификации поддерживается с 2019 года.
При этом оператор может сам сформировать нужные ему белые списки, например, команд управляющего протокола, чтобы исключить пропуск несанкционированной команды на ПЛК. И белые списки- не единственный механизм в PT ISIM для выявления нарушений, экспертиза АСУ ТП, входящая в состав продукта, позволяет делать однозначные выводы про состояние защищённости объекта КИИ, не опираясь только на один инцидент.
В начале работы, в режиме обучения, автоматически формируется белый список доверенных узлов и соединений, которые потом уточняются специалистами по ИБ. Все узлы и соединения не попавшие в белый список помечаются как неавторизованные и по ним заводятся соответствующие инциденты.