Добрый день! Не совсем так :) В 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.
Вы совершенно правы, для случая точечных атак, для которых запуск приложения уже является реализацией риска, такие правила малоэффективны, потому что при обнаружении факта атаки, уже не удастся избежать ущерба. Здесь нужно надеяться на средства предотвращения атаки и другие превентивные меры. Однако, в большинстве случаев, атаки намного сложнее и состоят из множества различных действий. Каждое действие можно поймать такими правилами.
Например, злоумышленники завладели узлом в DMZ и начинают проводить сетевую разведку для выбора следующей цели и продвижения по сети. Если обнаружить их на таком промежуточном этапе, то можно локализовать угрозу и избежать серьёзного ущерба.
Другим плюсом подобных проектов является наличие обширной базы знаний, накопленной разными исследователями. Так, посмотрев на то или иное правило, каждый специалист (администратор или сотрудник службы ИБ) может оценить насколько защищена его инфраструктура от подобных воздействий. Более того, такие базы знаний являются хорошими источниками гипотез при проведении Threat Hunting. Более подробно об этом мы рассказали тут: habr.com/ru/company/pt/blog/510362
Да, в репозитории Sigma на данный момент не так много правил для выявления атак в Unix-подобных системах. Это видно из таблицы со статистикой и визуализаций. Но в скором времени планируется второй спринт OSCD, на котором вы, при желании, сможете применить свои знания в этой области и расширить список правил для данного класса операционных систем. Привлечение большего внимания и участников к этому мероприятию кажется нам важной задачей.
imbasoft, teecat, спасибо за интерес к нашим стандартам. Бенчмарки PT Essential доступны пользователям продукта MaxPatrol 8. Познакомиться с ними можно с помощью бесплатной демоверсии этой системы. По ссылке можно оформить заявку для ее получения. Если будут какие-то вопросы – напишите нам на sales@ptsecurity.com, оперативно ответим.
Бояться гипотетической провокации преступников не стоит. В целевых атаках им по большей части все равно, как именно защищается цель: они намерены пробивать её защиту в любом случае. И в подавляющем большинстве случаев у них есть более значимый интерес, нежели просто проверить песочницу на слабо.
Цель песочницы именно в том, чтобы заставить потенциально опасный файл запуститься — от этого зависит, найдем мы угрозу или нет. Песочница — безопасный способ это сделать, так как ее виртуальная среда изолирована от инфраструктуры.
Вредоносные программы практически всегда проверяют, в какое окружение они попали – и не запускаются, если понимают, что находятся в песочнице. Если виртуальное окружение песочницы окажется совсем неинтересным (имя пользователя «test/test», например), зловред не запустится, песочница сочтет файл безопасным, он попадет в инфраструктуру и уже там нанесет ущерб.
В нашу эпоху шифрования всего расшифровать все, к несчастью (или счастью), не получится. Не все ПО использует стандартное TLS шифрование и стандартную проверку сертификатов. По нашему скромному мнению, в большинстве случаев расшифровка трафика для поиска злоумышленников не нужна. Но если очень хочется, то можно интегрировать в PT NAD специализированные инструменты дешифровки такого трафика.
Да, вы поняли верно – это может помочь. В качестве примера можно посмотреть эту запись: twitter.com/reecdeep/status/1184777885468508161 Но адреса С2 меняются, это общее решение. Также файлы .hta в данной волне атак не использовались для распространения полезной нагрузки, но можно и их добавить в список правил.
Спасибо! Мы сами до идеи простой техкарты дошли только в конце прошлого года, когда процессы сильно усложнились и поддерживать сложные процессные idef-модели оказалось не под силу :)
Конечно это могут быть и скомпрометированные машины и прокси. Однако все найденные IP при расследовании находятся в Азии и даже судя по тем местам где они оставили данные артефакты можно судить о недостаточной подготовленности атакующих. Поэтому данные IP скорее всего являются реальными адресами злоумышленников.
При этом оператор может сам сформировать нужные ему белые списки, например, команд управляющего протокола, чтобы исключить пропуск несанкционированной команды на ПЛК. И белые списки- не единственный механизм в 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
Например, злоумышленники завладели узлом в DMZ и начинают проводить сетевую разведку для выбора следующей цели и продвижения по сети. Если обнаружить их на таком промежуточном этапе, то можно локализовать угрозу и избежать серьёзного ущерба.
Другим плюсом подобных проектов является наличие обширной базы знаний, накопленной разными исследователями. Так, посмотрев на то или иное правило, каждый специалист (администратор или сотрудник службы ИБ) может оценить насколько защищена его инфраструктура от подобных воздействий. Более того, такие базы знаний являются хорошими источниками гипотез при проведении Threat Hunting. Более подробно об этом мы рассказали тут: habr.com/ru/company/pt/blog/510362
Здесь имелось ввиду "получить правильный формат ящика". Текст уточнили.
Цель песочницы именно в том, чтобы заставить потенциально опасный файл запуститься — от этого зависит, найдем мы угрозу или нет. Песочница — безопасный способ это сделать, так как ее виртуальная среда изолирована от инфраструктуры.
Вредоносные программы практически всегда проверяют, в какое окружение они попали – и не запускаются, если понимают, что находятся в песочнице. Если виртуальное окружение песочницы окажется совсем неинтересным (имя пользователя «test/test», например), зловред не запустится, песочница сочтет файл безопасным, он попадет в инфраструктуру и уже там нанесет ущерб.