Информационная безопасность АСУ ТП: Дон Кихот в эру кибероружия / Хабр

В данной статье проведена систематизация требований к информационной безопасности (ИБ) АСУ ТП. Требования выбраны из доступных на настоящий момент стандартов, в первую очередь, из

NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security»

и разрабатываемой новой редакции серии

ISA/IEC 62443 «Security for Industrial Automation and Control Systems»

.

АСУ ТП взаимодействуют с объектами физического мира и обеспечивают защиту от аварий и катастроф. В англоязычной литературе АСУ ТП называют Industrial Control Systems (ICS) или Industrial Automation and Control Systems (IACS). В мире IT технологий их можно сравнить с Дон Кихотом, который остался верен простым, но не очень модным принципам в уже давно изменившемся мире.

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

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

В чем отличие АСУ ТП от других информационных (IT) систем?

Прежде чем рассматривать вопрос ИБ, хорошо бы сначала разобраться, а что, собственно говоря, такого в АСУ ТП, что вопросы их защиты и безопасности необходимо рассматривать отдельно от всего мира других IT?

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

Сравнительный анализ информационных (IT) систем и АСУ ТП

Так в чем же все-таки проблема с информационной безопасность АСУ ТП?

Кроме того, что ИБ является проблемой сама по себе, в области АСУ ТП ситуация имеет свою специфику по причине наличия нескольких факторов.

Часто все обеспечение ИБ сводится к рассмотрению системы менеджмента ИБ (СМИБ), хотя СМИБ является необходимым, но не достаточным условием обеспечения ИБ для АСУ ТП. К тому же, в управлении ИБ АСУ ТП необходимо рассматривать три уровня: 1) предприятие, 2) программа по разработке и эксплуатации серии АСУ ТП, 3) единичная АСУ ТП. Об этом помнят не всегда, и происходит подмена понятий, когда для АСУ ТП, как технического объекта, пытаются выполнить все требования к СМИБ и упускают функциональные и технические характеристики.

Еще бывает так, что ИБ рассматривают только с точки зрения high-tech, как поток «черных» инноваций (Stuxnet, BlackEnergy, etc.) и, соответственно, набор тех или иных мер по защите от них.

Тем не менее, разумным является системный подход, включающий организационные и технические меры (триада «Люди – Процессы – Технологии»).

Еще одним моментом является лавинообразное увеличение за последние 5-10 лет количества стандартов в области ИБ. Многие стандарты активно перерабатываются и расширяются, что порождает некоторый хаос в требованиях.

Я постарался учесть стандарты и техдоки по АСУ ТП, а также те источники, на которые они ссылаются. Получился следующий обширный перечень:
– серия ISO/IEC 27000 “Information technology – Security techniques – Information security management systems” всем известна, и на хабре обсуждалась многократно, стандарты переводятся на русский язык и принимаются в качестве ГОСТ Р;
– три части ISO/IEC 15408 “Information technology – Security techniques –Evaluation criteria for IT security” или так называемые «Общие критерии» (Common Criteria) также переведены на русский язык и приняты в качестве ГОСТ Р;
– серия стандартов ISA/IEC 62443 “Security for Industrial Automation and Control Systems”; эти стандарты требуют самого тщательного внимания, поскольку представляют собой «энциклопедию» ИБ АСУ ТП; первая редакция была разработана International Society of Automation (ISA) в 2000-х гг., а затем адаптирована в качестве стандарта Международной электротехнической комиссии (МЭК, по-английски IEC); в РФ некоторые части 62433 также приняты в качестве ГОСТ Р; в настоящее время силами ISA ведется разработка следующей редакции 62433; разработка отстает от графика, но уже сейчас там есть о чем почитать; рисунок ниже показывает структуру планируемой серии ISA/IEC 62443;

Рисунок 1. Структура серии стандартов ISA/IEC 62443

– публикации States National Institute of Standards and Technology (NIST) на тему ИБ включают три серии: SP 500 Computer Systems, SP 800 Computer Security, SP 1800 Cybersecurity Practice Guides; NIST разработал собственную СМИБ (NIST SP 800-53 “Security and Privacy Controls for Federal Information Systems and Organizations”), а также Cybersecurity Framework (SCF); но нас наиболее интересует NIST SP 800-82 “Guide to Industrial Control Systems (ICS) Security”;
– публикации North American Electric Reliability Corporation (NERC) под общим названием Critical Infrastructure Protection (SIP), относящиеся, в первую очередь, к энергетическим системам;
– Cybersecurity Capability Maturity Model (C2M2), разработанная Министерством энергетики США (Department of Energy, DOE);
– рекомендованные практики, разработанные командой Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), входящей в состав Министерства внутренней безопасности США ( Department of Homeland Security, DHS);
– фреймворк Control Objectives for Information and Related Technologies (COBIT), разработанный International Professional Association ISACA;
– фреймворк Critical Security Controls for Effective Cyber Defense (CIS CSC) разработанный Center for Internet Security;
– также можно перечислить стандарты, разработанные для отдельных индустриальных отраслей, например, серия AGA 12 от American Gas Association (AGA), руководство API 1164 от American Petroleum Institute (API), применяемый на АЭС стандарт IEC 62645 “Nuclear power plants – Instrumentation and control systems – Cybersecurity requirements” и т.д.

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

Теперь остается еще один вопрос: как совместить требования к информационной безопасности с требованиями к функциональной безопасности (ФБ)? Последняя важна тем, что АСУ ТП управляют физическими потенциально опасными объектами, и именно в этом состоят их основные риски.

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

Правда и то, что «надежностники» тоже скептически смотрят на security, не видя особых проблем в кибер угрозах. Системы безопасности (противоаварийной защиты, ПАЗ) крайне консервативны, поскольку требуют больших затрат на лицензирование и сертификацию. Например, для АЭС затраты на лицензирование могут составлять до 10% стоимости проекта.

Так что, иного пути, чем междисциплинарная интеграция усилий и знаний, на данный момент не существует. Гармонизация требований к ИБ и ФБ тоже будет рассмотрена ниже в данной публикации.

Общая картина требований к информационной безопасности АСУ ТП

Когда рассматривается какая-либо техническая система, связанная с возможными рисками, то алгоритм формирования требований к ней следующий:

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

Когда я об этом, задумался, то общая картина у меня представилась таким образом.

Рисунок 2. Концепция информационной безопасности

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

Рисунок 3. Контекст обеспечения и оценивания информационной безопасности (источник: ISA/IEC 62443)

На особенностях описания АСУ ТП и концепции обеспечения ИБ необходимо остановиться подробнее.

Описание АСУ ТП

Для описания особенностей разберемся с тремя типами моделей АСУ ТП, которые предлагается рассматривать в интересах ИБ.

Прежде всего, это референсная модель АСУ ТП, определяющая пять уровней:

– Уровень 4: управление предприятием;
– Уровень 3: операционное управление производством;
– Уровень 2: управление и мониторинг физических процессов (SCADA);
– Уровень 1: локальное управление процессом и оборудованием, включая функции защиты и безопасности (Control System);
– Уровень 0: физический процесс и оборудование (датчики и исполнительные механизмы).
То, что обычно подразумевается под АСУ ТП, по сути занимает уровни 0, 1 и 2.

Рисунок 4. Референсная модель АСУ ТП (источник: ISA/IEC 62443)

Модель физической архитектуры АСУ ТП является наиболее распространенной. Она описывает физические компоненты, объединенные посредством сетей.

Рисунок 5. Модель физической архитектуры АСУ ТП (источник: ISA/IEC 62443)

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

Рисунок 6 Модель зонирования АСУ ТП (источник: ISA/IEC 62443)

Далее, процесс обеспечения ИБ зависит от определения того, как АСУ ТП применяется на целевом объекте. Такое описание включает:

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

Концепция обеспечения информационной безопасности

Уровни информационной безопасности

В основе концепции обеспечения ИБ лежит деление АСУ ТП на уровни ИБ (Security Level, SL). Определяются уровни ИБ в зависимости от характерных угроз и уязвимостей, рисков, целевых функций частей и компонентов АСУ ТП, и, связанных с этим политик безопасности.

Считается, что уровни ИБ заимствованы из ранее предложенных и успешно применяемых в АСУ ТП уровней ФБ, называемых также Safety Integrity Level (SIL).

В стандартах можно найти несколько подходов к разделению АСУ ТП на Security Level. Мы остановимся на зонировании, предложенном все в том же ISA/IEC 62443:

– Security Level 0 (No specific requirements or security protection necessary); определение уровня, для которого не нужны меры обеспечения ИБ, порождает некоторую неопределенность, поскольку непонятно, можно ли вообще отказаться от обеспечения ИБ; на практике можно руководствоваться конкретной ситуацией и исходить из принципа разумной достаточности; обычно нулевой уровень устанавливается не для зон в целом, а для отдельных компонентов, который по какой-либо причине не дотягивают до следующего уровня Security Level 1;
– Security Level 1 (Protection against casual or coincidental violation); защита от случайных или совпадающих нарушений ИБ обеспечивается, в первую очередь, процедурным путем;
– Security Level 2 (Protection against intentional violation using simple means with low resources, generic skills and low motivation); начиная со второго уровня, рассматривается защита от злонамеренных нарушений; на втором уровне рассматриваются обычные неспециализированные атаки, такие как вирусы или использование известных уязвимостей; обычно такие атаки отражаются в автоматическом режиме;
– Security Level 3 (Protection against intentional violation using sophisticated means with moderate resources, ICS specific skills and moderate motivation); на данном уровне необходимо обеспечить защиты от злоумышленников, обладающих достаточными знаниями и ресурсами, чтобы совершить атаку на целевую систему; такие злоумышленники используют малоизвестные уязвимости операционных систем и индустриальных протоколов, а также программные инструменты, которые требуют специальных знаний;
– Security Level 4 (Protection against intentional violation using sophisticated means with extended resources, ICS specific skills and high motivation); данный уровень отличается от предыдущего тем, что здесь злоумышленник привлекает значительные ресурсы, например, организованная группа может использовать кластер компьютеров с высокой вычислительной мощностью на продолжении длительного времени.

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

Для каждого из уровней ИБ в АСУ ТП задается несколько групп требований:

– управление идентификацией и аутентификацией;
– контроль использования ресурсов;
– обеспечение интегрированности (целостности);
– обеспечение конфиденциальности данных;
– доступность ресурсов;
– контроль и ограничение потоков данных;
– время реакции на события.

Соответственно, объем рассмотренных ниже требований к СМИБ, жизненному циклу АСУ ТП и защитным контрмерам зависит от установленного уровня ИБ.

Система менеджмента информационной безопасности

По проблеме организации СМИБ уже существует множество материалов. Важно помнить, что менеджмент СМИБ может устанавливаться на нескольких уровнях: 1) предприятие, 2) программа по разработке и эксплуатации серии АСУ ТП, 3) единичная АСУ ТП.

Для СМИБ уровня предприятия, как для управленческой системы, реализуется цикл Деминга: Plan – Do – Check – Act.

Для СМИБ, применяемой в рамках проектов по разработке АСУ ТП, реализуется жизненный цикл, который рассмотрен ниже.

Жизненный цикл информационной безопасности

Для АСУ ТП реализуется V-образный жизненный цикл, который характеризуется выполнением мероприятий по верикации и валидации (обзоры, анализ или тестирование после каждого из этапов разработки). Пример жизненного цикла разработки ПО для АСУ ТП представлен ниже.

Рисунок 7. V-образный жизненный цикл разработки ПО АСУ ТП (источник: IEC 61508)

Данный жизненный цикл реализует требования к ФБ и потому называется Functional Safety Life Cycle. Для того, чтобы соответствовать Security Life Cycle, в спецификации должны быть определены требования к ИБ. Требования к ИБ должны включать реализацию направленных на снижение рисков контрмер, таких, как обеспечение конфиденциальности, интегрированности и доступности, управление идентификацией и аутентификацией и т.д. Эти требования затем реализуются и проверяются на всех этапах жизненного цикла.

Важной концепцией ИБ является «защита в глубину» (Defense in Depth), также пришедшая из области ФБ. «Защита в глубину» подобна многоуровневой глубокоэшелонированной обороне, когда, после проникновения атакующего через один из защитных уровней, он встречается с новой, возможно, принципиально другой защитой атакуемого объекта.

Связь информационной и функциональной безопасности

В публикациях на тему функциональной безопасности мне удалось свести все многообразие требований к нескольким группам:

— управление функциональной безопасностью (Functional Safety Management);
— реализация жизненного цикла функциональной безопасности (Functional Safety Life Cycle);
— защита от систематических отказов проектирования системы и ПО (System and Software Failures Avoidance);
— защита от случайных отказов аппаратных средств (Random Failures Avoidance).

Рисунок 8. Концепция требований к функциональной безопасности

Если спроецировать эти группы требований на область ИБ, то картина получится приблизительно та же.

Во-первых, исходя из роли АСУ ТП в обеспечении ФБ и ИБ, производится градация и разделение систем на уровни. Для обеспечения и оценивания ФБ вводятся Safety Integrity Levels (SIL), а для обеспечения и оценивания ИБ – Security Levels (SL).

Во-вторых, в рамках СМИБ должно быть реализовано управление ИБ. Поскольку многие процессы ИБ и ФБ имеют пересечение, между ними должна осуществляться координация.

В-третьих, как было показано выше, процессы разработки, верификации и валидации, направленные на обеспечение как ФБ, так и ИБ, могут быть реализованы в рамках единого жизненного цикла (Safety & Security Life Cycle).

В-четвертых, в области ФБ и ИБ есть общие риски, обусловленные возможными отказами аппаратных средств. Методами защиты от таких отказов являются резервирование, диагностирование, защита от помех и других экстремальных воздействий и т.п. Таким образом, для обеспечения ИБ и ФБ применяются одни и те же контрмеры.

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

И, наконец, в рамках управления ИБ и ФБ должно осуществляться оценивание мер по обеспечению этих двух составляющих безопасности.

Все сказанное выше представлено на диаграмме, которая может быть основой для координации деятельности по обеспечению ИБ и ФБ.

Рисунок 9. Концепция гармонизированных требований к функциональной и информационной безопасности

Выводы

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

С учетом вышесказанного, обеспечение и оценивание информационной и функциональной безопасности АСУ ТП должно осуществляться координировано в рамках единого жизненного цикла (Safety & Security Life Cycle).

Решение проблемы информационной и функциональной безопасности АСУ ТП лежит в как в организационной, так и в технической плоскости.

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

Среди технических мер по защите АСУ ТП наиболее эффективным является размещение оборудования и ПО в зонах с различным уровнем информационной безопасности (Security Level), среди которых наивысший уровень имеет зона, включающая систему противоаварийной защиты (ПАЗ). Еще одной эффективной технической мерой может быть использование специализированного (проприетарного) ПО, такого, как операционные системы и сетевые протоколы.

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

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

Остальные уязвимости можно и нужно устранять в рамках уже наработанного индустрией опыта, руководствуясь концепцией построения защиты в глубину (Defense in Depth). Однако, механизмы хакерских атак будут также развиваться, и нулевого риска здесь быть не может.

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

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