УЦСБ – Безопасная разработка для АСУ ТП внедрение подходов на примере разработки SCADA

0:01 По памяти следующий доклад у нас будет от представителя айти компании от системного интегратора от разработчика решений для крупных инфраструктурных объектов. Компания у ЦСБ Илья Новотарский, я надеюсь, я вспомнил, что. Встречает. Здравствуйте, рад всех приветствовать, сегодня расскажу про опыт нашей компании при работе с на примере Скада Систем. Меня зовут Ульяна Войдарский, я занимаюсь управлением продукта АП. Сейф в направлении безопасной разработки у ЦСБ и в том числе про этот продукт. Сегодня я вам расскажу, я есть основные темы, которые мы раскроем это требование 239 приказа в СтЭК К.

1:04 Значимым объектам критической инфраструктуры расскажу про то, как АП сейф помогает разработчикам Скада систем. Привнести безопасную разработку в их процесс и про особенности проектирования скада систем с точки зрения безопасной разработки. С чем мы столкнулись, но если времени останется, то в том числе про сертификацию дополнил и. Может быть, по вершкам успею это рассказать? Ну, начнем с 239 приказа, в сущности, он делится на 3 домена. Основные это разработка с учетом требований безопасности с точки зрения. Именно процесса безопасной разработки он должен быть должны проводиться регулярные проверки программного обеспечения по мере его жизненного цикла, ну и поддержка безопасности. Имеется ввиду, что мы не просто что то находим мы. Проблема также должны найдены устранять. Ну, рассмотрим чуть подробнее 1 домен, это разработка с учетом требований безопасности. Здесь мы ориентируемся на ГОСТ по безопасной разработке 56 939 от 24 года. Он не имеет декларативный характер, не требует, то есть он рекомендательный характер имеет и.

2:35 Его хорошо использовать при описании своих процессов при выстраивании процесса безопасной разработки, потому как этот гост создает такую. Дает возможность говорить на 1 языке с регулятором и не имеет, как я сказал ранее. Прямых требований, которым нужно подчиняться дальше, необходимо моделировать угрозы, делается по методологиям. Страйд и паста, и для 1. Категории значимых объектов, в том числе нужно описывать поверхность атаки, все модули, которые входят в состав по и взаимодействием.

3:15 Далее перейдем к. К блоку Секундочку. Секунду, да? Регулярные испытания, да это статический анализ, анализ композиционный, то есть, когда мы анализируем по на предмет наличия в нем сторонних компонентов. И смотрим периодически и и появились ли какие нибудь новые известные уязвимости в этих компонентах, также фазинг тестирования есть определенные.

3:50 Рекомендации методологии в стека, которые надо тут соблюдать и для 1 категории. Зооки и в том числе и динамический анализ, то есть нужно будет выстроить стенд и на нем проверять собственно уязвимости в рантайме и поддержка безопасности. Но тут имеется ввиду, что, как я говорил. Ранее, что мы периодически анализируем приложение, периодически в нем находим проблемы и не просто находим, мы на них реагируем. Отправляем эти проблемы разработке и следим за тем, чтобы они устранялись.

4:31 Также в случае, если мы поставляем свое по какому то заказчику, то мы должны уведомить о том, что у нас в составе есть некоторые уязвимости, которые не устранены. Потому что если проанализировать любое приложение и попытаться. Устранить там все уязвимости, но это колоссальный труд и в основном в 1 очередь именно самые эксплуатируемые критичные вещи устраняются. Ну и в случае опять же с 1 категорией объектов, это в том числе нужно проработать процедуры. Информирования о том, что вы завершаете разработку по или его поддержку, но это то, о чем нам говорит приказ в СтЭК. А сейчас ближе к тому, как наш продукт АП сейф, собственно, на кейсах помог разработчикам Скада. Тут Высокоуровнева работает. Таким образом, что в нашей платформе есть модули для регулярной проверки, собственно, исходного кода. Аналитик проверяет легитимность, то есть актуальность обнаруженных проблем, верифицирует их и по итогу информация это передается.

5:52 В разработку даются отчеты и дается описание нашей платформы и таким образом регулятору этого достаточно для того, чтобы понять, что те вышеописанные требования. Достаточно, чтобы понять, что требования соблюдены. Также вот немножко по стандартам их становится все больше в области безопасной разработки. Какие то носят рекомендательный характер, какие то приказы имеют обязательный. Характер, но это касается государственных информационных систем субъектов Кии и так дальше. Ну, есть отраслевые стандарты, которые также имеют себе элементы безопасной разработки.

6:35 И это та сфера, за которой нужно продолжать следить, потому что? Актуальность именно подхода к безопасной разработке растет, это подтверждается регуляциями вниманием со стороны государства. Ну ближе к кейсам в целом для нас как для безопасной разработки. Скада оказалась немножко непривычной с той точки зрения, что у. У Скада разработчиков зачастую нет в штате специалистов по безопасной разработке. То есть, если есть ребята из информационной безопасности, это хорошо, но компетенции. По безопасной разработке нет и нет понимания, как весь процесс выстраивать, с чего начинать. И к чему в конечном итоге приходить и осложняется ситуация тем, что?

7:30 Ситуация осложняется тем, что все таки приходится сталкиваться с некоторыми технологическими реалиями, в рамках которых. Есть иногда устаревшее оборудование, которое работает на устаревших стандартах, протоколах, и в связи с этим некоторые требования банально невозможно. Некоторые рекомендации стандартов не всегда удается легко положить на технологические реалии.

7:59 Кейс Атомиксофт на самом деле. Объемная платформа 6 основных компонентов, которые общаются между собой, написанные на Си. + + + надо признаться, не самая типичная, не самое типичное приложение и. Логика его функционирования, и когда мы уже непосредственно подключали к нашему продукту АП сейф эту платформу, мы столкнулись с тем, что коробочными решениями мы не покрываем. Вот тот объем кода, который в платформе присутствует, то есть проверки, то проходят, а уязвимостей не находится. И в этой связи приняли решение, что будем писать свои правила для разбора в.

8:53 Для поиска уязвимостей для статического анализатора и на данный момент написали порядка 100 правил, которые и дают основной поток находок. Основной поток уязвимостей, которые обнаруживаются, устраняются и как итог вся эта. Информация попадает не просто в отчет, ну, то есть, возможно, и оформление отчетов периодическое, но также дополнительно еще подключается. Стас трекер, куда информация об уязвимости направляется и там уже аналитика расписывает.

9:28 Что за уязвимость, чем грозит и как ее устранять? То есть связь с разработчиками прямая и кроме тикетов, кроме отчетов, также проводятся встречи с разработчиками, объясняются? Собственно, те проблемы, которые были найдены, почему мы считаем, что они актуальны, их нужно устранять, в том числе таким вот образом в иногда случается. Иногда случается повлиять на приоритетность устранения уязвимостей, потому что у команды есть понимание о том, что за приложения, какие там уязвимости, чем это опасно конкретно в.

10:08 Это этом контексте другой кейс, это тоже скад. Разработчик Сибком цифра все то же самое подключились, проанализировали, выдали результат, рассказали разработчикам, и также проблемы устраняются. И сейчас немножко от такой маркетинговой части мы перейдем к. Тем особенностям, с которыми мы столкнулись и. Вот Касперский ведет статистику об атаках на Скады системы, и, по их данным, за последний год каждая 5 система Скада подверглась той или иной атаке. Обычно это какой нибудь фишинг или атаки там. Через цепочки поставок самые популярные такие вещи через почтовые рассылки и и вызвано. Это опять же тем, что из за сложностей запад, необходимости поддержания лего сикода из за необходимости.

11:14 Работать с устаревшим оборудованием. Вся экосистема. Разработки таких систем представляет из себя лакомый кусочек для разного рода агентов угрозы, потому что. Можно получить большие бенефиты минимальными затратами и. Есть они, осознавая эти риски. Были рождены различные стандарты, которые имеют рекомендательный характер, которые описывают компенсационные меры для снижения уровня риска, но. Зачастую в полной мере эти рекомендации приземлить на землю не получается, поэтому приходится искать какой то другой подход, ну, например, если.

12:09 Мы там, например, используем, у нас есть требования. Обеспечить зашифрованное взаимодействие между компонентами, а у нас используется старый протокол, который не поддерживает современные способы шифрования. Приходится искать различные обходные пути об этом чуть позже, побольше, чуть далее. Есть такой вот 1 из вызовов, это собственно ролевая модель, как ее выстроить, потому что. Не не всегда возможно внедрить жесткие ограничения при работе при работе системы опять же, потому что и жесткие ограничения по производительности системы. Мы не можем ее замедлять, мы не можем что то блокировать.

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

13:37 Выполняемых действий, так сказать, должностным инструкциям этого компонента. Да, дальше мы погружаемся в сложности контроля целостности. То есть мы не хотим, чтобы какой то сторонний код начал выполняться на нашем оборудовании, не хотим, чтобы. У нас. Датчики начали показывать некорректную информацию и в этой связи. Решением может быть. Выстраивание такой системы, где мы для? элементов, которые у нас есть, прописываем динамически, прописываем их нормальное состояние в определенный момент времени и сравниваем их текущее состояние С.

14:34 Это, собственно говоря тем, который мы задали, как эталон. И если мы не можем блокировать какие то действия, то мы приходим к тому, что мы смещаем немножко парадигму с блокирования. На мониторинг постоянный и быстрое реагирование, то есть если у нас и произошла какая то подмена кода, подмена конфигурации, то мы об этом быстро получаем информацию, реагируем.

15:06 Далее. Есть рекомендации и требования, если мы. Работаем с данными грифа секретно это. Аудит логов, то есть у нас должна быть система, которая будет записывать все логи. С неотказуемостью от авторства таким образом, чтобы в случае, если злоумышленник проникнет к нам в сеть, чтобы он не смог замести и следы своего пребывания. Перезаписать конфиги, и это также необходимо реализовывать отдельное внимание. Я, к сожалению, не успею об этом глубже рассказать. Можете подойти к нам на стенд и и наш. Инженер расскажет подробнее это про меры обеспечения постоянной доступности. Но если кратко, то мы не можем просто взять и дублировать всю инфраструктуру зачастую. По различным соображениям, поэтому тут мы исходили из того, что мы делаем горячее резервирование для наиболее критичных компонентов и холодная для вторичных.

16:17 Далее уязвимости через цепочки поставок с этим тоже нужно работать здесь из области безопасности. Приложения есть ответ системы класса сца софтверкомпозишн анализе, то есть мы, мы не можем просто выпустить приложение. И сказать, что на дату релиза там были обнаружены н уязвимостей и сколько то из них мы устранили. И все потому, что если мы используем, а мы, скорее всего, используем сторонние компоненты у консорстной библиотеки.

16:51 В них периодически находятся уязвимости, есть разная статистика, но так, если Верхнеуровневая 70.% 70 Любое библиотек, так или иначе, в каких то версиях своих содержат уязвимости и. Собственно, инструменты класса сца позволяют периодически анализировать, какие у нас компоненты в системе есть и какие уязвимости. В открытых источниках также есть, чтобы вовремя реагировать атаки на цепочки поставок.

17:27 Дефейсы и прочие вещи нам не хотелось бы видеть и остановку работы системы, поэтому такие вещи надо проверять и. Про защиту трафика это вам лучше, Виктор расскажет. Я тут даже не буду в его поле заходить. Это затравочка на поход на стенд приглашаем вас еще раз. И когда мы говорим также про многофакторную аутентификацию, ее тоже бывает сложно реализовать, потому что нету иногда возможности на всех пользователей выкатить единую систему, которая бы автоматически отдавала и. Отбирала бы доступ, поэтому в 1 кейсе был реализован, организован АПИ Гейтвей, через который все запросы централизованно заходили. И можно было уже там, на уровне аппетит, в как то контролировать легитимность этих запросов.

18:32 Ну и немножечко буквально остается про сертификацию, наверное. Я просто в общих словах скажу, не успею я в нее углубиться. То, что есть вот набор для Заоки обязательных требований в стека России и. Для получения сертификации необходимо пройти определенные процедуры, в которых участвуют как сами органы по сертификации, так и испытательной. Лаборатории, ну и наша команда, в том числе, имеет обширный опыт в сертификации собственно продуктов с айфоны, проект про это и есть в. Том числе и да, мы сможем наши коллеги смогут помочь в этом разобраться. У нас еще остается минутка, может быть, если останется время на. Вопросы я бы на них ответил, а так на остальные вопросы, особенно по проектированию, наши коллеги смогут ответить на стенде более обстоятельно.

19:49 Лучше в микрофон. Раз раз отлично, Дмитрий Лукашевич, руководитель разработки. Подскажите, пожалуйста, в свое в своей разработке вы говорите, используйте образ компоненты, как решаете 2 проблемы, 1 это в исходнике. Скомпрометированы, ну, например, кейсы КЗет библиотеки. Если помните, да, а 2 то, что бинарники, которые вы скачиваете из репазитории артефактов, не соответствует сходникам сами компилити или пока забили на это?

20:24 Ну вообще все используют опенсорские компоненты, и тут необходимо вообще иметь выстроенный по хорошему. Есть всякие артефактории, где мы можем хранить артефакты, которые у нас в разработке используются. Не имеется в виду, когда мы, когда мы у себя разрабатываем, у нас нет бинарников. К счастью, мы бинарники не берем в случае, если все таки взяли бинарники, в составе которых есть уязвимости в библиотеках, то тогда по хорошему. Нужно смотреть, что за уязвимости и ну там на самом деле не целый набор мер. Может быть, но в идеале там самая горячая мера. Это просто выключить по возможности из оборота бинарник до тех пор, пока не будет понятно там. Вендор, исправит ли или же мы закроемся на уровне там, в паблике Ишин Фаервола или на уровне других средств? С бинарниками сложнее, чем я. Правильно понимаю, что вы веселый панцер, который используете компилите сами из? Исходников его, ну, конечно, его не обязательно всегда компилировать в зависимости от языка по разному работает, но так уважаемые участники. Давайте немножко прервемся, спасибо большое, Илья Тайминг, время давайте уважать наших.

21:48 Попалагируем Илье за очень хороший доклад.

Расшифровка сделана автоматически (Yandex SpeechKit) и может содержать ошибки в терминах.