Компании по ИБ предлагают утилиты для проверки ПК на угрозы, в том числе в прошивках.
Но если компьютер заражен, то угроза может быть скрыта от СЗИ и не будет обнаружена.
Эффективнее обнаруживать внедрение буткитов на стадии заражения, в том числе с использованием песочниц.
Стоит детально изучать такие активности, если они отличаются от типичных в инфраструктуре. На примере удаленного создания сервиса: такая активность, исходящая с сервера 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 на нашем мероприятии тоже надо было получить доступ, далеко не все команды нашли способ проникнуть в сегмент АСУ ТП.
Добрый день! Вы абсолютно правы: PT BlackBox Scanner предназначен для проведения внешнего сканирования веб-приложений на наличие в них уязвимостей.
Касаемо полученных вами результатов – мы будем очень признательны, если вы напишете нам на feedback.bbs@ptsecurity.com и в двух словах расскажете о тех уязвимостях, которые PT BlackBox Scanner увидел/не увидел конкретно в вашем кейсе. Для разбора ситуации необходим детальный анализ. Спасибо!
Можете поподробнее рассказать как устроен ваш репозиторий на aptly?
Полное зеркало официального + снэпшоты? Из официальных репозиториев мы забираем только установочные файлы, udeb и deb пакеты.
Делаете ли deb пакеты со своими разработками или собираете бинарь в докере?
Делаем свои пакеты и выкладываем в свой артефакторий, аптли для этого не используется. Докер контейнеры так же выкладываются в артефакторий после сборки из внешних пакетов с aptly и наших пакетов с артифактория.
Фиксируете ли версии того, что сами пишите в Dockerfile?
В докер файлах релизных контейнеров фиксируем снепшот аптли для данного релиза.
Кто дергает API? curl в недрах CI или что-то другое?
Добрый день! Все зависит от задачи, которую вы хотите решить. Самым бюджетным решением является аренда VPS с последующим развертыванием необходимых инструментов и проведением сканирования. Можно воспользоваться бесплатным облачным сканером для веб-приложений от Positive Technologies (https://bbs.ptsecurity.com/ru). Также может подойти упомянутый нами Shodan.
Но если компьютер заражен, то угроза может быть скрыта от СЗИ и не будет обнаружена.
Эффективнее обнаруживать внедрение буткитов на стадии заражения, в том числе с использованием песочниц.
Спасибо, поправили)))
Стоит детально изучать такие активности, если они отличаются от типичных в инфраструктуре. На примере удаленного создания сервиса: такая активность, исходящая с сервера 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 для выявления нарушений, экспертиза АСУ ТП, входящая в состав продукта, позволяет делать однозначные выводы про состояние защищённости объекта КИИ, не опираясь только на один инцидент.
В начале работы, в режиме обучения, автоматически формируется белый список доверенных узлов и соединений, которые потом уточняются специалистами по ИБ. Все узлы и соединения не попавшие в белый список помечаются как неавторизованные и по ним заводятся соответствующие инциденты.
Касаемо полученных вами результатов – мы будем очень признательны, если вы напишете нам на feedback.bbs@ptsecurity.com и в двух словах расскажете о тех уязвимостях, которые PT BlackBox Scanner увидел/не увидел конкретно в вашем кейсе. Для разбора ситуации необходим детальный анализ. Спасибо!
Полное зеркало официального + снэпшоты? Из официальных репозиториев мы забираем только установочные файлы, udeb и deb пакеты.
Делаем свои пакеты и выкладываем в свой артефакторий, аптли для этого не используется. Докер контейнеры так же выкладываются в артефакторий после сборки из внешних пакетов с aptly и наших пакетов с артифактория.
В докер файлах релизных контейнеров фиксируем снепшот аптли для данного релиза.
Работа с аптли реализована через GitLab CI и командно строчный интерфейс, это связано с рядом причин, например необходимостью запуска встроенного в аптли web сервера и проблемами обработки слеша. github.com/aptly-dev/aptly/issues/115 github.com/aptly-dev/aptly/issues/561