Открытая архитектура и кибербезопасность АСУ ТП – залог успеха

---

Открытая архитектура и кибербезопасность АСУ ТП – залог успеха

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

Меня зовут Владимир Карантаев, я лидер Центра практической кибербезопасности, Центра национально-технологической инициативы Московского энергетического института, кандидат технических наук. Последние лет, наверное, 10-12 занимаюсь с экспертной точки зрения кибербезопасностью АСУ ТП, и поэтому сегодняшняя конференция, конечно, очень мне по профилю.

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

Правильный подход, если эти все технологии изначально будут разрабатываться в защищенном виде, как с точки зрения процесса, так и с точки зрения технологий, которые используются. Поэтому я одно от другого не отделяю.

Вообще в рамках этого комитета рассматривались уже вопросы кибербезопасности? И вообще вы участвуете в работе комитета?

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

Для начала определить объект, который мы изучаем, то есть как будет выглядеть конечная система. А потом сформировать подход к моделированию угроз, для того чтобы потом в свою очередь предложить функциональные требования и другие типы требований для построения этой системы изначально в защищенном виде. Вот мне кажется, в этом наша главная задача общая.

Я так понимаю, что сейчас система еще выглядит очень эфемерно, абстрактно. Поскольку даже еще требования к ней не сформулированы до конца.

Наверное, есть какой-то общий контур, который мы и обсуждаем. Собственно говоря, мои коллеги по рабочей группе информационной безопасности взяли на себя такой колоссальный труд описать вот этот объект, который мы исследуем. То есть вот эта потенциальная АСУ ТП открытой архитектуры, из каких элементов она будет состоять, как объект защиты.

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

На каких началах вы и ваши коллеги принимаете участие в работе этой группы?

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

У нас, во-первых, есть в этом опыт. Почему? Потому что электроэнергетика в этом смысле, она немножко впереди. То есть там есть такое понятие – цифровые подстанции или высокоавтоматизированные подстанции. И эту задачу отрасль начала решать, ну, наверное, уже больше, чем 10 лет назад. И как раз на похожих принципах.

Тогда лет 10 назад речь о кибербезопасности еще не шла серьезно.

Знаете, и да, и нет. На самом деле, вот я об этом люблю говорить, применительно к электроэнергетике. Еще в 2013 году было одно из первых экспертных заседаний в России, где был прямо поднят вопрос, что применение новых технологий в системах автоматизации, автоматики, объектов электроэнергетики поднимает вопрос обеспечения кибербезопасности. То есть это было задолго, до 22-го года и, например, других событий. То есть это точно вопрос поднимался. 

Другой момент, что сейчас то, что мы обсуждаем, будет строиться на новом технологическом стеке. И это очень удобная точка, чтобы построить систему изначально в защищенном виде.

Как на ваш взгляд, не является ли противоречием изначальные планы делать open-source продукты и сделать их абсолютно кибербезопасными? Считается всегда, что open-source совсем не кибербезопасно.

Это сложный вопрос, очень комплексный. Я попробую короткими тезисами отвечать. С одной стороны, нужно признать, что тренд последних лет – это так называемые атаки на цепочку поставки. Что это значит? Это значит, что атаки на процесс разработки open-source ПО тоже были. 

Внедрить свой код на этапе…

Да, то есть люди, злоумышленники, давайте их так назовем, долгое время мимикрировали под хороших разработчиков. И когда им ментейнер начинал верить, они начинали делать какие-то свои дела. Это нам нужно иметь в виду. Это раз. Вот я об этом как раз и говорил. Тут можно воспринимать как, что open-source – это какое-то совместное решение технологической задачи.

Это не значит, что мы получаем какой-то пригодный к применению продукт. Дальше у нас есть существующая система оценки соответствия как в области информационной безопасности, так и в области, например, надежности, функциональной надежности, функциональной безопасности. Разработка чего-либо в open-source ни в коей мере не отменяет процедуру оценки соответствия требованиям.

Поэтому, к примеру, я приведу, как с этим мы уже сейчас работаем. Есть институт системного программирования Российской Академии Наук, в котором создан консорциум по изучению ядра Linux и других системных компонентов. Зачем? Чтобы как раз коллективно оценить, насколько мы им можем доверять. Такими словами скажу. Да, мы в этом центре тоже участвуем.

Возможно, это тоже путь. То есть, когда какие-то компоненты мы сделаем для АСУ ТП, для какой-то архитектуры, по такому же подходу, например, оценивать их еще и в консорциуме, о котором я сказал.

А как это физически можно будет реализовать? Смотрите, я так понял, что консорциум сейчас планирует что? Ну вот в части, например, софт ПЛК. Софт ПЛК это один всего лишь из продуктов. Вот мы делаем базовый open source продукт, выкладываем исходный код, условно говоря, на GitHub. Любой может оттуда взять его и портировать на свою какую-то аппаратную платформу и пользоваться ей. Получается, что тестирование на предмет уязвимостей, контроль того, что это абсолютно безопасный продукт, без всяких закладок, – это будет проблема каждого, кто возьмет этот код и начнет им пользоваться. Тогда получается, что это решение небезопасное.

Абсолютно безопасного не бывает. Тут надо это тоже понимать. Это на самом деле вопрос. Несколько раз он поднимался. Что такое в том числе АСУ ТП открытой архитектуры? Это еще изменение бизнес-модели.

Это изменение структуры рынка АСУ ТП, когда совместимость решений достигается за счет соответствия требованиям стандарта. Когда мы обсуждали требования к этим решениям с точки зрения безопасности, мы в том числе обсуждали требования к жизненному циклу, то есть требования к разработке. Это то, что называют разработкой безопасного ПО.

Поэтому, на мой взгляд, здесь будут стадии. Стадия разработки чего-то в парадигме open source, а потом все равно будет разработка коммерческого продукта из этого тем или иным участником. И уже в этой процедуре всего скорее на этом этапе должны быть предъявлены требования по безопасной разработке.

И здесь нужно сказать, что в этом году вышел обновленный гос по безопасной разработке 56939, наш регулятор в области ИБ ФСТЭК России, вышел приказ, который определяет порядок сертификации процесса безопасной разработки. И, на мой взгляд, участникам, в том числе рабочей группы, нужно к этому просто готовиться. Что такое готовиться? Это, в первую очередь, экспертиза в процессах и практике безопасной разработки. А их достаточно много. Там, по-моему, 26 процессов описаны и много практик. 

Как Вы считаете, реалистичны ли сроки выхода готового продукта, которые здесь анонсировались?

Я даже на эту тему выступал несколько лет назад на конференции в Альтэнергетике. Я говорил о том, что такая эффективная кооперация – это определенная проблема. То есть у нас очень слабо строится кооперация от разработчика, допустим, дизайн-центра микропроцессора через разработчика системного модуля и к ОЕМ-производителю, ну и разработчики ПО. Но если эта кооперация на базе рабочей группы будет строиться и не порушится, то мы имеем шанс, что это будет происходить ускорее.

Скоординировать всех.

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

Второе – это консолидация спроса на защищенные встраиваемые операционные системы реального времени, плюс другие компоненты, которые бы повысили защищенность. Например, это встраиваемая криптография, отечественные средства криптографической защиты информации, программно- или программно-аппаратные. И в этом смысле, на мой взгляд, рабочие группы и такие конференции, они этому точно способствуют.

Вот здесь кто-то из докладчиков такую смешную, интересную мысль высказал, что все, конечно, согласны, что надо это делать, и не получилось бы так, что все будут сидеть и ждать, кто первый в это дело ввяжется, и не расшибет ли он себе лоб на этом. А вот если у него получится, вот тогда и мы подтянемся. Как переломить эту ситуацию?

В чем уникальность этой рабочей группы? То, что изначально во всех экспертных рабочих группах лидировали представители компаний-заказчиков из той или иной отрасли, из металлургии, химии, нефтегаза и так далее. То есть они как бы направляли всех.

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

То есть они будут понятными для них потенциальными заказчиками.

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

Значит, Вы считаете, что дело перспективное и вполне осуществимое? 

А какой у нас выбор?

Вот сегодня мне чем конференция понравилась? На мой взгляд, сегодня был такой уникальный сплав специалистов. Были представители компаний, дизайн-центров, то есть это микроэлектроника, были представители компаний, которые разрабатывают софт от операционной системы до прикладного ПО Runtime, мы с Вами слышали доклады. Были представители компаний, которые делают конечные изделия, были заказчики. То есть вот эта площадка, и то, как это организовано, как раз и позволяют верить в конечный успех. 

Другой вопрос, что Вы задали все правильные вопросы. То есть если не будет понятного плана, не будет вот этой самой лидерской истории, что вот мы, компания А, хотим получить открытую архитектуру АСУ ТП у себя в обозначенные сроки, и для этого мы создали вот такие возможности. Приходите к нам. Вот если так будет построено, все будет хорошо. 

Предпосылки к эффективной кооперации есть. Значит, понимание технологического стека тоже есть. Но при этом есть ряд вопросов, которые мы должны системно решить. Это вопросы с микроэлектроникой, вопросы с системным ПО. То есть это вся экосистема от загрузки, операционная система, Runtime и все прочее, то, что мы сегодня обсуждали. Но и при этом важно будет сохранение позиции компаний-заказчиков, которые за это уже взялись.

Чтобы они не отказались.

Да, да. Если это все одно за другим остается как задумано и продолжает свою реализацию, то у нас есть все шансы на успех. Более того, задача поставлена, ведь мы же все знаем, разрабатываем так называемый доверенный программно-аппаратный комплекс. Постановление 1912. И те планы, которые формируют федеральные органы исполнительной власти в каждой из отраслей, по идее могли бы учитывать происходящее здесь. То, что, например, какая-то доля из этих планов будет учитывать планы, например, деятельности рабочего...

На уровне серверов и цодов используется все, а на уровне АСУ ТП почему-то никто не вспоминает об этом.

И здесь важный момент. Что такое доверенный пак? В постановлении есть три критерия. Это железо должно быть в реестре Минпромторга, ПО должно быть в реестре Минцифры, а если в паке реализуются функции безопасности, эти функции должны быть сертифицированы соответствующими регуляторами. На мой взгляд, все понятно.

Мы ровно это сегодня и обсуждали. Другой вопрос, что вот в этой палитре технологий, конечно, у нас большой объем работы, но просто нужно брать и делать.


© СТА-ПРЕСС, 2024