Приложение А (справочное). Описание вектора SL

Приложение А
(справочное)

Описание
вектора SL

Примечание 1 - Данное приложение основано на документе "Уровни обеспечения безопасности: векторный подход к описанию требований безопасности" [28]. Содержание этого исходного документа преобразовано в содержание данного приложения в соответствии с изменениями в серии МЭК 62443 и комментариями, полученными от рецензентов.

Примечание 2 - Первоисточниками большей части материала, содержащегося в данном приложении, являются МЭК 62443-1-1 и МЭК 62443-3-2. На момент публикации настоящего документа эти документы разрабатывались и/или перерабатывались и не содержали материала по вектору SL. Данное приложение приведено в целях разъяснения читателю концепции вектора SL. Материал данного приложения - информативный и может быть замещен любым обязательным содержимым вышеперечисленных стандартов.

А.1 Обзор

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

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

А.2 Уровни безопасности

А.2.1 Определение

Далее приведена выдержка из МЭК/ТС 62443-1-1:2009 (см. 5.11.1), в которой в наглядной форме объясняется, что такое уровни SL и как их можно использовать.

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

На своем первом этапе разработки серия стандартов МЭК 62443 оперирует больше качественными SL, используя такие термины, как "низкий", "средний" и "высокий". От собственника объекта потребуется представить собственное определение того, что значат эти классификации применительно к его конкретной прикладной системе. Долгосрочная цель серии МЭК 62443 - свести как можно больше уровней и требований безопасности к количественным описаниям, требованиям и системам показателей для создания условий повторной применимости стандарта в пределах группы организаций и отраслей промышленности. Достижение этой цели займет время, поскольку потребуется приобретение дополнительного опыта применения стандартов и данных к промышленным системам безопасности для мотивирования количественного подхода.

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

А.2.2 Типы SL

SL разбиты на три различных типа: целевые, достигнутые и потенциальные. Эти типы, будучи взаимосвязаны, затрагивают разные аспекты жизненного цикла безопасности:

- целевые SL (SL-T) - это желаемые уровни безопасности для отдельно взятой системы. Эти уровни обычно определяются посредством выполнения оценки рисков для системы и установления того, что она нуждается в конкретном уровне безопасности для гарантированного обеспечения своего корректного функционирования;

- достигнутые SL (SL-A) - это фактические уровни безопасности для отдельно взятой системы. Эти уровни измеряются после доступности проекта системы или когда система установлена и действует. Они служат для установления того, что система безопасности отвечает целям, которые были с самого начала обозначены в целевых SL;

- потенциальные SL (SL-C) - это уровни безопасности, которые могут обеспечивать компоненты или системы, будучи корректно сконфигурированными. Эти уровни указывают, что тот или иной компонент или система изначально способны соответствовать целевым SL без помощи дополнительных компенсационных контрмер, будучи корректно сконфигурированными и интегрированными.

Каждый из этих SL рассчитан на использование на разных этапах жизненного цикла безопасности в соответствии с серией МЭК 62443. Начиная с формулировки цели для конкретной системы: организации потребуется разработать проект, который освещал бы потенциальные возможности для достижения желаемого результата. Другими словами, команде разработчиков сначала предстоит разработать целевой SL, необходимый для конкретной системы. Затем им предстоит разработать систему, отвечающую этим целям, как правило - методом итерационного подхода, при котором после каждой итерации достигнутые SL выдвинутого проекта определяются и сравниваются с целевыми SL. В качестве составляющей такого подхода разработки разработчикам предстоит выбрать компоненты и системы, для которых необходимые потенциальные SL должны соответствовать требованиям целевых SL, или же, в случае недоступности таких систем и компонентов, дополнить доступные компоненты и системы компенсационными контрмерами. После сдачи системы в эксплуатацию предстоит определить фактический SL, являющий собой достигнутый SL, и сравнить его с целевым SL.

А.2.3 Применение уровней SL

При разработке новой системы (зеленое поле) или пересмотре безопасности существующей системы (коричневое поле) первым шагом необходимо разбить систему на разные зоны и определить тракты, связывающие эти зоны между собой там, где это необходимо. Подробности по осуществлению этого приведены в МЭК 62443-3-2. Как только установлена зональная модель системы, каждой зоне и тракту присваивается целевой SL, на основе анализа последствий, который описывает желаемую безопасность для соответствующей зоны или тракта. Во время этого исходного анализа зон и трактов не нужно завершать детальный проект системы. Достаточно описать функциональность, которую по возможности должны обеспечивать объекты в зоне, и соединения между зонами, чтобы достигались цели безопасности.

Рисунки А.1 и А.2 иллюстрируют общие примеры систем, разбитых на зоны, соединенные между собой трактами. На рисунке А.1 представлено графическое изображение системы управления станцией загрузки цистерны с хлорином. Полный сценарий использования, дополняющий этот рисунок, будет рассмотрен в МЭК/ТТ 62443-1-4. На рисунке показано пять зон: BPCS, SIS, центр управления, DMZ производственного объекта и предприятие. И BPCS, и SIS используют контроллеры PLC для управления различными аспектами станции загрузки, при этом SIS использует специальный PLC функциональной безопасности (PLC-FS), рассчитанный на использование в системах физической безопасности. Оба PLC соединены между собой через немаршрутизируемое последовательное или Интернет-соединение с использованием устройства защиты границ. Каждый из PLC соединен с местным коммутатором, который осуществляет переключение между рабочей станцией инженера, предназначенной для программирования, и устройством HMI, предназначенным для управления. Зоны с BPCS и SIS содержат также IAMS, предназначенную для снятия показаний с контрольно-измерительных приборов и их поверки. Центр управления, содержащий серию рабочих станций, и BPCS соединены с DMZ производственного объекта. DMZ производственного объекта может содержать самые разнообразные компоненты и системы, например сервер-архиватор и рабочую станцию техобслуживания, как показано на рисунке. DMZ производственного объекта показана в соединении с корпоративными системами, которые содержат корпоративную WLAN и веб-сервер. На рисунке показано несколько контроллеров домена и устройств защиты границ для обозначения некоторых контрмер, которые могут применяться для повышения безопасности.

Рисунок А.1 - Общий пример из обрабатывающей промышленности, иллюстрирующий зоны и тракты

На рисунке А.2 представлено графическое изображение производственного объекта. Он содержит четыре обозначенные зоны: корпоративную сеть, промышленно-корпоративную DMZ и две промышленные сети. Корпоративная инфраструктура включает в себя WLAN и соединение с Интернетом. Многие организации используют DMZ между важными частями их систем, предназначенную для изоляции сетевого трафика. В данном конкретном примере каждая промышленная сеть функционирует относительно независимо от другой промышленной сети и при этом содержит свой PLC, периферийные устройства и HMI.

Рисунок А.2 - Общий пример производства, иллюстрирующий зоны и тракты

После определения целевых SL система может быть разработана (зеленое поле) или переработана (коричневое поле) в целях соответствия этим целевым SL. Процесс разработки обычно являет собой итеративный подход, при котором проект системы сравнивается с целью несколько раз в процессе его разработки. Ряд частей серии МЭК 62443 содержит методологическую основу по различным аспектам программных и технических требований, которые появляются в процессе разработки. МЭК 62443-2-1 предоставляет методологическую основу по программным аспектам процесса разработки, в то время как МЭК 62443-3-3 (настоящий стандарт) и МЭК 62443-4-2 [10] обозначают требования технической безопасности уровня системы и уровня компонентов и соотносят их с различными потенциальными SL.

В процессе разработки системы необходимо оценить характеристики безопасности различных компонентов и подсистем. Поставщики продуктов должны будут предоставлять эти характеристики в виде потенциальных SL для их компонентов или систем, сопоставив признаки и характеристики с требованиями, определенными в серии МЭК 62443 для различных потенциальных SL. Эти потенциальные SL могут служить для определения того, может ли тот или иной компонент или система соответствовать целевому SL системы. Поставщик продуктов или системный интегратор должен будет также предоставить методологическую основу по конфигурированию компонента или системы для их соответствия заявленным SL.

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

После утверждения и реализации проекта системы она должна быть проанализирована для предотвращения или смягчения последствий снижения уровня безопасности системы. Ее следует анализировать во время или после модификаций системы и на систематической основе. МЭК 62443-2-1 предоставляет методологическую основу по необходимой последовательности действий для ведения программы безопасности и оценке ее эффективности. После определения достигнутых SL потребуется оценить, соответствует ли система изначальным целевым SL (например, используя системные требования из МЭК 62443-3-3). Если система не соответствует этим требованиям, на то может быть несколько причин, включая недостаточное сопровождение программы или необходимость переработки частей системы.

В сущности, характеристики безопасности системы управления определяются независимо от контекста отдельно взятого использования, но используются в отдельно взятом контексте для достижения целевого SL архитектуры, зон и/или трактов соответствующей системы (см. рисунок А.3).

Рисунок A.3 - Схема взаимосвязей использования различных типов SL

А.3 Вектор SL

А.3.1 Фундаментальные требования

Уровни SL основаны на семи FR безопасности, определенных в МЭК 62443-1-1:

1) управление идентификацией и аутентификацией (IAC);

2) контроль использования (UC);

3) целостность системы (SI);

4) конфиденциальность данных (DC);

5) ограничение потока данных (RDF);

6) своевременный отклик на события (TRE) и

7) работоспособность и доступность ресурсов (RA).

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

А.3.2 Определения уровней

А.3.2.1 Обзор

Стандарты серии МЭК 62443 определяют уровни SL с точки зрения пяти различных уровней (0, 1, 2, 3 и 4) по степени возрастания безопасности. Актуальная модель для определения SL соотносится с угрозой, которая непрерывно усложняется, и незначительно разнится в зависимости от типа SL, к которому она привязана. Применительно к SL-С это означает, что собственник объекта или системный интегратор способны сконфигурировать конкретный компонент или систему для отражения непрерывно усложняющейся угрозы. Применительно к SL-T это означает, что собственник объекта или системный интегратор определили посредством анализа рисков, что должны защищать данную конкретную зону, систему или компонент от угрозы этого уровня. Применительно к SL-A это означает, что собственник объекта, системный интегратор, поставщик продуктов и/или любое их объединение сконфигурировали зону, систему или компонент для их соответствия конкретным требованиям безопасности, определенным для этого SL.

В формулировках для каждого SL используются такие термины, как "случайный", "непредумышленный", "простой", "изощренный" и "обширный". Эти формулировки умышленно абстрактны, чтобы одни и те же базовые формулировки можно было использовать для всех документов серии МЭК 62443. Каждый отдельный документ серии будет определять требования для уровней SL, которые соотносятся с его конкретными назначениями.

Хотя требования для каждого SL будут различны на протяжении всей серии МЭК 62443, необходимо иметь общее представление о том, от чего по возможности должен защищать каждый SL. Следующие фрагменты предоставят некоторую методологическую основу к разграничению уровней SL.

А.3.2.2 SL 0: Не требуется специальных требований или защиты безопасности

SL 0 имеет несколько значений, зависящих от ситуации, в которой он применяется. В рамках определения SL-С он будет означать, что компонент или система не могут удовлетворять некоторым из требований SL 1 для данного конкретного FR. С наибольшей вероятностью это будет относиться к компонентам или системам, являющимся частью обширной зоны, в которой другие компоненты или системы будут обеспечивать компенсационные контрмеры. При определении SL-Т для отдельно взятой зоны он означает, что собственник объектов определил следующее: результаты анализа рисков показывают, что для данного конкретного FR к данному компоненту или системе необходимы специальные требования уровня меньшего, чем полный SL 1. Это будет скорее относиться к отдельным компонентам внутри системы или зоны, никак не влияющим на конкретные FR. При определении SL-A он будет означать, что отдельно взятая зона не может удовлетворять некоторым требованиям SL 1 для данного конкретного FR.

А.3.2.3 SL 1: Защита от случайного или непредумышленного нарушения безопасности

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

В соответствии с рисунком А.1 простым примером будет оператор, способный изменить уставку на инженерной станции в зоне BPCS до значения, не соответствующего условиям, которые определены инженерным персоналом. Система не установила должных ограничений на аутентификацию и контроль использования, чтобы оператор не смог внести изменения. Также в соответствии с рисунком А.1, другим примером будет пароль, высылаемый открытым текстом по тракту между зоной BPCS и зоной DMZ, что позволяет сетевому инженеру видеть пароль в процессе устранения неполадок в системе. Система не установила должной конфиденциальности данных для защиты пароля. В соответствии с рисунком А.2 третьим примером будет инженер, который собирается получить доступ к PLC в Промышленной сети #1, но в результате получает доступ к PLC в Промышленной сети #2. Система не установила должного ограничения потока данных, что предотвратило бы получение инженером доступа к ошибочной системе.

А.3.2.4 SL 2: Защита от умышленного нарушения безопасности с использованием простых средств при незначительных ресурсах, посредственных навыках и низкой мотивации

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

В соответствии с рисунком А.1 примером будет вирус, который инфицирует рабочую станцию техобслуживания в DMZ производственного объекта, откуда распространяется на рабочую станцию инженера BPCS, поскольку обе они используют одинаковую универсальную операционную систему. В соответствии с рисунком А.2 другим примером будет злоумышленник, нарушающий безопасность веб-сервера в корпоративной сети посредством эксплойта, загруженного из Интернета, в случае общеизвестной уязвимости в универсальной операционной системе веб-сервера. Злоумышленник использует веб-сервер в качестве отправной точки атаки на другие системы корпоративной сети, а также промышленной сети. Также в соответствии с рисунком А.2 третьим примером будет оператор, просматривающий сайт на HMI, расположенном в Промышленной сети #1, который загружает троян, и этот троян открывает в маршрутизаторах и межсетевых экранах лазейку в Интернет.

А.3.2.5 SL 3: Защита от умышленного нарушения безопасности с использованием изощренных средств, при умеренных ресурсах, наличии специальных познаний в IACS и умеренной мотивации

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

Примером изощренных средств могут быть инструменты для взлома паролей или ключей, основанные на хеш-таблицах. Эти инструменты доступны для загрузки, но их применение требует знания системы (например, хеша взламываемого пароля). В соответствии с рисунком А.1 примером будет злоумышленник, который получает доступ к PLC-FS через последовательный тракт после получения доступа к управляющему PLC через уязвимость в контроллере Интернет. В соответствии с рисунком А.2 третьим примером будет злоумышленник, который получает доступ к серверу-архиватору через межсетевой экран промышленно-корпоративной ДМ3 посредством атаки перебором, инициированной из корпоративной беспроводной сети.

A.3.2.6 SL 4: Защита от умышленного нарушения безопасности с использованием изощренных средств, при обширных ресурсах, наличии специальных познаний в IACS и высокой мотивации

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

Примером изощренных средств при обширных ресурсах будет использование супер-ЭВМ или кластеров ЭВМ для осуществления взлома паролей методом перебора с использованием обширных хеш-таблиц. Другим примером будет ботнет, используемый для атаки на систему одновременно с помощью нескольких векторов атак. Третьим примером будет организованная преступная группировка, имеющая достаточную мотивацию и ресурсы, чтобы недели подряд пытаться анализировать систему и разрабатывать собственные эксплойты "нулевого дня".

А.3.3 Формат вектора SL

Для описания требований безопасности зоны, тракта, компонента или системы может использоваться вектор как лучшая альтернатива единичному номеру. Данный вектор может содержать либо требование конкретного SL, либо нулевое значение для каждого из фундаментальных требований (см. А.3.1).

ФОРМАТ - SL-? ([FR,] домен) = {IAC UC SI DC RDF TRE RA},

где SL-? = (Требуемый) Тип SL (см. А.2.2). Возможны следующие форматы:

- SL-T = Целевой SL;

- SL-A= Достигнутый SL;

- SL-C = Потенциальный SL

[FR,] = (При необходимости) Поле, обозначающее FR, к которому относится значение SL. FR записываются в форме текстового сокращения, а не чисел для удобства чтения.

Домен = (Обязательно) Подходящий домен, на который распространяется SL. Домены могут относиться к зонам, системам управления, подсистемам или компонентам. Вот некоторые примеры различных доменов, которые представлены на рисунке А.1: зона SIS, зона BPCS, зона HMI BPCS, контроллер домена DMZ производственного объекта, тракт от DMZ производственного объекта к Центру управления и последовательный тракт от SIS к BPCS. В данном конкретном стандарте все требования относятся к системе управления, поэтому термин "домен" здесь не используется в противоположность другим документам серии МЭК 62443.

Примеры -

1 SL-T(Зона BPCS) ={2201313}

2 SL-C(ACB Рабочая станция инженера) {3 3 23 001}

3 SL-C(RA, PLC-FS) = 4

Примечание - Последний пример раскрывает только компонент RA 7-значного SL-C.