1. Сформулируйте критерии защищенности ИТ-инфраструктур КВО.

Возможно применение трех следующих критериев для оценки защищенности КВО. Первый критерий — соответствие уровня безопасности КВО некому целевому уровню (описание уровней см. чуть ниже). Второй — выполнение так называемого принципа «чёрного ящика». Это такое состояние, когда любая информация об объекте не покидает пределов информационной системы (особенно она не должна попадать в публичные источники), а любое внешнее воздействие на информационную систему исключается. Третий критерий — количество инцидентов.

Стандарт IEC 62443-1-1 предлагает следующие уровни ИБ:

• «Нулевой» уровень безопасности или Уровень безопасности 0 (УБ0) – требования информационной безопасности отсутствуют;
• Уровень безопасности 1 (УБ1) – для защиты от случайных или непреднамеренных нарушений (угроз);
• Уровень безопасности 2 (УБ2) – для защиты от преднамеренных нарушений (угроз) с применением простых средств и минимальных ресурсов, требующих общих навыков и минимальной мотивации;
• Уровень безопасности 3 (УБ3) – защита от преднамеренных нарушений (угроз) с применением сложных средств и умеренных ресурсов, требующих специфичных для объекта защиты навыков и умеренной мотивации;
• Уровень безопасности 4 (УБ4) – защита от преднамеренных нарушений (угроз) с применением сложных средств и максимальных ресурсов, требующих специфичных для объекта защиты навыков и максимальной мотивации.

2. Назовите известные вам ИБ-риски, специфичные для КВО и отранжируйте их по величинам возможного ущерба.

Целевой уровень безопасности (первый вопрос) как раз и определяется набором рисков. Риски для КВО можно поделить на две большие группы: общие риски, присущие большинству объектов и риски, специфичные для какой-либо отрасли. Также, риски делятся на риски для самого объекта защиты и риски для его окружения. Например, при ЧП на объекте могут пострадать люди, непосредственно работающие на нём, и люди, которые живут рядом с объектом.

Общие риски:

• Количество раненых людей, не требующих госпитализации
• Количество раненых людей, требующих госпитализации
• Количество погибших людей
• Ущерб активам (здания, сооружения, оборудование)
• Экономический ущерб
• Ущерб окружающей среде
• Репутационный ущерб.

Как видно, эти риски можно также поделить на группы: социальные (связанные с жизнью и благополучием человека), экономические и материальные, ущерб окружающей среде и репутационный ущерб. Последний пункт достаточно неочевидный, но, тем не менее, такой риск тоже существует. В качестве примера может послужить авария на добывающей платформе BP в Мексиканском заливе в апреле 2010 года. Акции компании значительно упали в цене, а выявление фактов сокрытия информации о проводимых работах и масштабе аварии нанесло огромный репутационный ущерб.

Специфичные риски для отрасли (пример для энергетики), которые определяются специалистами (этот список может быть расширен ими):

• Количество отключенных потребителей
• Длительность отключений (часы, дни, недели, месяцы)
• Стабильность электропитания (качество электроэнергии)
• Потеря генерирующих мощностей (МВт)

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

3. Какие компоненты ИТ-инфраструктур КВО являются наиболее уязвимыми и требуют первоочередного внимания?

Вне всякого сомнения, самое первое, на что стоит обратить внимание — это защита АРМ. Как показывает практика, именно рабочие места операторов технологических процессов являются самыми уязвимыми. Это связано, прежде всего, с режимом их функционирования. Они должны работать и работают в режиме 24/7, а для обновления операционных систем, прикладного и защитного программного обеспечения зачастую требуется перезагрузка. Поэтому такие обновления происходят только во время технологических окон, которые могут появляться всего один-два раза в год. Вторая распространённая уязвимость АРМ — низкая сложность или полное отсутствие паролей. Понятно, что безопасностью здесь пожертвовали в угоду доступности, но как показывают проведённые нами аудиты и тесты на проникновение, подобрать пароль рабочего места — дело очень непродолжительного времени. А листочек с паролем, приклеенный под монитором — совсем не фантастика, к сожалению.

Второй возможный вектор атаки — общая для корпоративных и технологических сервисов и систем сетевая инфраструктура. Понятно, что получив контроль над коммутатором, злоумышленник будет иметь возможность не только получать интересующую его информацию, но и влиять на технологический процесс. Уязвимости большого количества сетевого оборудования хорошо и подробно описаны, а ограничения на обновления ПО на нём такие же, как и на АРМ. Также злоумышленника может ждать приятный «бонус» — по одной и той же сетевой инфраструктуре происходит передача информации не только технологической информационной системы, но и корпоративной ИС. Там, где это действительно нужно, они, конечно, разделяются, но обычно для экономии используются одни и те же сети. Такая ситуация позволяет злоумышленнику атаковать технологическую сеть из корпоративной, и наоборот. Виртуализация пока не слишком широко применяется на КВО, но общие тенденции в ИТ и ИБ говорят о том, что в скором времени станут актуальны и специфичные для виртуализированных сред угрозы. То есть в случае использования виртуальных корпоративных и технологических сервисов в единой виртуальной среде, возникают аналогичные угрозы проникновения из корпоративных сегментов в технологические через общее звено (виртуальную платформу).

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

4. Какие факторы (архитектурные, технологические, организационные или иные) затрудняют защиту ИТ-инфраструктур КВО?

Технологические ограничения связаны с режимом функционирования систем — это непрерывное функционирование в круглосуточном режиме и связанные с этим сложности, о которых уже говорилось выше.

Организационные ограничения связаны с тем, что службы ИТ и эксплуатации АСУТП имеют отличные от службы ИБ приоритеты. У одних это доступность информационных ресурсов и непрерывность работы, у других — обеспечение безопасности. Ещё одна сложность — длительная процедура согласования любых работ между многочисленными службами, включая обслуживающие компании-аутсорсеры.

5. Нужны ли для защиты ИТ-инфраструктур КВО принципиально новые ИБ-методы и ИБ-продукты? Какие?

В настоящий момент есть две основных тенденции R&D в сфере обеспечения безопасности автоматизированных технологических систем. Первая — встраивание инструментов обеспечения ИБ непосредственно в саму технологическую систему (контроллеры, исполняющие устройства, пункты технологического и диспетчерского управления, специализированное программное обеспечение) ещё на стадии проектирования и производства. То есть, чтобы система была защищена «из коробки». Это позволит в большой степени избежать тех ограничений, которые были описаны в п. 4, потому что «навешивать» дополнительные системы на АСУТП концептуально неправильно. Но пока нам приходится это делать.

Второе направление — исследования в области «умных» обновлений. Такие обновления программного обеспечения АСУТП должны вести себя предсказуемо при установке, то есть система не должна «падать», должны корректно приниматься настройки, установка апдейтов должна проходить без остановки технологического процесса. Уже есть проекты АСУТП, которые сами следят за корректностью установки обновлений. Как это происходит: предположим, что обновление успешно прошло тестирование на макете и в «песочнице», но при установке на функционирующую систему происходит какой-либо сбой и остановка техпроцесса (сейчас такая ситуация — ночной кошмар службы эксплуатации). Новое поколение АСУТП в подобном случае само поймёт, что что-то пошло не так, подаст об этом сигнал и самостоятельно примет меры по недопущению остановки технологического процесса. Исследования в этой области уже финансируются Департаментом энергетики США.

6. Готова ли ИБ-индустрия, в первую очередь отечественная, сегодня обеспечить защиту ИТ-инфраструктур КВО?

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

7. Как вы оцениваете состояние российской регулятивной базы, относящейся к области ИБ КВО?

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