четверг, 22 ноября 2018 г.

Информационная безопасность интернета вещей: кто вещь, а кто хозяин?

источник

Ни для кого не секрет, что в области интернета вещей (Internet of Things, IoT), пожалуй, меньше всего порядка в плане обеспечения информационной безопасности (ИБ). Сегодня мы наблюдаем развивающуюся технологию, постоянно меняющийся ландшафт отрасли, прогнозы, порой уводящие в сторону от реальности, десятки организаций, пытающихся объявить себя законодателями в той или иной области, хотя бы «на час». Актуальность проблемы подчеркивается эпическими инцидентами. Industroyer, BrickerBot, Mirai – и это лишь видимая верхушка айсберга, а что «день грядущий нам готовит»?

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

Несколько особняком стоит промышленный интернет вещей (Industrial Internet of Things, IIoT), включающий, в том числе, объекты критической информационной инфраструктуры (КИИ). Операторы IIoT систем привыкли внедрять достаточно зрелые технические решения с горизонтом эксплуатации в десятки лет. Таким образом, внедрение модернизаций и инноваций с использованием IIoT решений сдерживается динамичностью рынка с отсутствием общепринятой системы стандартов и общепринятых схем лицензирования.

Еще один вопрос: что делать с морем информации, накопленной в области ИБ IoT за последние 3-4 года? Что нужно взять за основу, а что является второстепенным? А если в разных документах встретилась противоречивая информация, то, что важнее? Одним из ответов может быть изучение аналитических отчетов, в которых обобщен и гармонизирован накопленный опыт с учетом максимального числа доступных источников.

В ноябре 2018 ENISA (The European Union Agency for Network and Information Security) выпустило документ «Good Practices for Security of Internet of Things in the context of Smart Manufacturing», в котором собраны всевозможные практики обеспечения кибербезопасности для промышленного интернета вещей, причем проанализировано около сотни документов с лучшими практиками в этой области. Что же находится «под капотом» этой попытки объять необъятное? В статье выполнен обзор содержания.

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

На сайте National Institute of Standards and Technology (NIST) можно обнаружить документ «Draft NISTIR 8200. Interagency Report on Status of International Cybersecurity Standardization for the Internet of Things (IoT)». Версия датирована февралем 2018, и пока все еще носит статус драфта. Там проводится анализ существующих стандартов, распределенных по следующим 11 областям: Cryptographic Techniques, Cyber Incident Management, Hardware Assurance, Identity and Access Management, Information Security Management Systems (ISMS), IT System Security Evaluation, Network Security, Security Automation and Continuous Monitoring (SACM), Software Assurance, Supply Chain Risk Management (SCRM), System Security Engineering.

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

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

Ниже на рисунке представлена структура документа, и мы с ней сейчас детально ознакомимся.



Первая часть является вводной.
Во второй части сначала приводится базовая терминология (2.1), а затем вызовы в обеспечении безопасности (2.2), к которым относятся:
- уязвимые компоненты (Vulnerable components);
недостатки в управлении процессами (Management of processes);
- возростающее количесво коммуникационных связей (Increased connectivity);
- взаимодействие операционных и информационных технологий (IT/OT convergence);
- наследование проблем АСУ ТП (Legacy industrial control systems);
- небезопасные протоколы (Insecure protocols);
- человеческий фактор (Human factors);
- избыточная функциональность (Unused functionalities);
- необходимость учета аспектов функциональной безопасности (Safety aspects);
- реализация обновлений, связанных с ИБ (Security updates);
- реализация жизненного цикла ИБ (Secure product lifecycle).

В разделе 2.3, со ссылкой на ISA, приведена референсная архитектура, которая, тем не менне, несколько противоречит общепринятой архитектуре ISA (Purdu), поскольку RTU и PLC отнесены ко 2-му, а не к 1-му уровню (как это практикуется в ISA).


Референсная архитектура IIoT

Референсная архитектура является входом для формирования таксономии активов, которая выполнена в разделе 2.4. На основании экспертных данных оценена критичность активов с точки зрения их влияния на ИБ. О репрезентативности речь не идет (в отчете сказано, что участвовали эксперты от 42 различных организаций), и можно воспринимать эту статистику, как «некоторое мнение». Проценты на диаграмме означают процент экспертов, которые оценили тот или иной актив, как наиболее критичный.

Экспертная оценка критичности активов IIoT

В разделе 3.1 выполнена классификация и описание возможных угроз, применительно к области IIoT. Кроме того, к каждой из угроз привязаны классы активов, которые могут быть затронуты. Выделены основные классы угроз:
- Nefarious activity / Abuse (недобросовестная деятельность и злоупотребления) – различного рода манипуляции, производимые с данными и устройствами;
- Eavesdropping / Interception / Hijacking (прослушивание / перехват / хакинг) – сбор информации и взлом системы;
- Unintentional damages (accidental) (непреднамеренные случайные повреждения) – ошибки в конфигурировании, администрировании и применении;
- Outages (отключения) – перебои в работе, связанные с потерей электропитания, коммуникаций или сервисов;
- Disaster (катастрофы) – разрушительные внешние воздействия природного и техногенного характера;
- Physical attack (физические атаки) – воровство, вандализм и саботаж (вывод из строя), производимый непосредственно на оборудовании;
- Failures / Malfunctions (отказы и нарушения в работе) – могут происходить по причине случайных отказов аппаратных средств, по причине отказов сервисов провайдера, а также из-за проблем в разработке программного обеспечения, приводящего в внесению уязвимостей;
- Legal (правовые вопросы) – отклонения от требований законов и контрактов.


Таксономия угроз

В разделе 3.2 рассмотрены типовые примеры атак на компоненты систем IIoT.

Самый важный раздел в документе – это 4-й, в котором рассмотрены лучшие практики, направленные на защиту компонентов IIoT. В практики включены три категории: политики, организационные практики и технические практики.


Структура лучших практик обеспечения ИБ IIoT

Принципиальное различие политик и организационных практик не объяснено, а процедурный уровень присутствует в обоих случаях. Например, Risk and Threat Management попали в политики, а Vulnerability Management – в организационные практики. Единственное различие, которое можно уловить, это то, что политики применяются, в первую очередь, для разработчиков, а организационные практики – для эксплуатирующих организаций.

В составе политик (4.2) описаны 4 категории и 24 практики. В организационном разделе (4.3) описано 27 практик, разделенных на 6 категорий, а в техническом (4.4) – 59 практик, разделенных на 10 категорий.

В Приложении А отмечено, что настоящим документом ENISA продолжает исследования, задекларированные в 2017 г. в документе «Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures». Конечно, IoT более широкое понятие, чем IIoT, и, с этой точки зрения, можно было бы взять прошлогодний документ за основу этого обзора, однако, всегда хочется иметь дело с более новым материалом.

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


Фрагмент описания лучших практик обеспечения ИБ IIoT


В Приложении С дан перечень цитируемых документов (их всего около 100), которые были проработаны и легли в основу разработанных лучших практик.
В Приложении D перечислены самые значимые инциденты, связанные с нарушением ИБ в промышленных приложениях.

Выводы

«Good Practices for Security of Internet of Things in the context of Smart Manufacturing», разработанный в ноябре 2018, является на сегодняшний момент одним из самым подробный документов в области ИБ интернета вещей. Подробной технической информации по реализации 110 описанных практик нет, однако, есть свод накопленных знаний, полученный на основе анализа сотни документов от ведущих экспертных организаций в области IoT.

Документ сфокусирован на IIoT, учитывает промышленную архитектуру и связанные с ней, активы, угрозы и сценарии возможных атак. Более общим для IoT является документ-предшественник ENISA «Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures», выпущенный в 2017.

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

вторник, 23 октября 2018 г.

Обзор презентаций шестой конференции по промышленной кибербезопасности (Сочи, 19-21.09.2018)

source

«Лаборатория Касперского» опубликовала пресс релиз о шестой конференции по промышленной кибербезопасности (Сочи, 19-21.09.2018), организатором которой она же и являлась.

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

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

1. Обзоры о состоянии дел в промышленной кибербезопасности в целом – 5 докладов

Из обзорных докладов, безусловно, надо отметить «Think like a hacker, but act like an engineer» (Marty Edwards, International Society of Automation), который открывал конференцию и задавал ей тон. Здесь и сравнительный анализ информационных и операционных технологий (IT-OT), и тренды в недостатках киберзащиты по мотивам U.S. ICS-CERT, и анализ последствий инцидентов, и типовой сценарий атаки и многое другое, с одной стороны, очевидное и известное, с другой стороны, системно и оригинально изложенное. Прозвучали два тренда, которые представляются мне важными: сближение с областью safety (функциональная безопасности) и важность применения фреймворка NIST по кибербезопасности. Многоаспектный интересный обзор с качественной инфографикой представлен в «50 shades of ICS security controls» (Ibrahim Samir Hamad, An Oil & Gas Company). Интересной и познавательной статистикой впечатлил доклад «Five myths of industrial cybersecurity» (Evgeny Goncharov, Kaspersky Lab).

2. Презентации компаний и продуктов – 10 докладов

«Продуктовые» или «продажные» презентации вызывают больше всего нареканий, хотя все и понимают, что вендоры едут на конференции, чтобы «продавать». В Сочи, мне думается, баланс был соблюден, поскольку презентации продуктов сопровождались и общей теоретической составляющей, и интересными техническими подробностями. Особенно интересными, на мой взгляд, получились «KICS*HICS=Tested and protected» (Ruslan Stefanov, Honeywell), а также «A complex approach to industrial cyberdefense in the age of digitalization» (Yan Sukhikh, Schneider Electric).

3. Отдельные технологии обеспечения кибербезопасности – 7 докладов

В области технологий можно уйти в попытку объять необъятное, или в очевидные вещи, или в сложные технические подробности, понятные лишь хакерам. Организаторам же удалось представить несколько интересных и важных направлений: проблемы облачных технологий, анализ атак с использованием удаленных средств администрирования, honeypots fingerprinting, мониторинг угроз, компрометация отключенных от интернета систем. Отличный анализ целевых APT (Advanced Persistent Threat) атак сделан в докладе «Attribution in a world of cyber espionage» (Yury Namestnikov, Kaspersky Lab).
Пожалуй, одна из самых важных презентаций конференции – это «Security PHA review for analyzing process plant vulnerability to cyberattack» (Edward Marszal, Kenexis). Эдвард стал заниматься кибербезопасностью, имея огромный опыт в области анализа рисков и функциональной безопасности. Поэтому, основной его тезис – кибербезопасность должна основываться на рисках процесса. Такая оценка базируется на методе HAZOP (Hazard and Operability study) и его разновидности для процессов, PHA (Process Hazard Analysis). Методы эти несколько десятков лет применяются в области функциональной безопасности. В докладе говорится только о количественной оценке (детерминированный подход), хотя, если в таблицы добавить вероятности событий, то можно перейти к количественной оценке. На сайте Kenexis много полезной информации (что редкость для консалтинговых компаний): шаблоны таблиц для анализа, руководства, статьи. Пишут, что даже базовую версию своего инструментального средства, OPEN PHA, они предоставляют бесплатно.

4. Особенности обеспечения кибербезопасности в отдельных промышленных отраслях – 7 докладов

Все презентации очень познавательны, поскольку рассказывают об особенных сферах, с которыми мы сталкиваемся не каждый день, и, зачастую, даже не догадываемся об их удивительной специфике. Хороший обзор тенденций современного автопрома представлен в «How digital transformation enables Ferrari to be even faster» (Remigio Armano, Ferrari), хотя непосредственно про кибербезопасность там сказано не так уж и много. Феерична история захода «Лаборатории Касперского» на автомобильный рынок: сначала спонсируем гоночную команду, а потом обеспечиваем кибербезопасность. Очень интересный доклад был по применению IoT-решений на яхтах «Swimming IoT: A hackers journey into the secrets of modern yacht (in)security» (Stephan Gerling, Rosen Group), настоящая романтика кибербезопасности. На конференции не было презентаций от «традиционных» отраслей (энергетика, авионика, химия, нефтегаз). Пожалуй, информация об этих отраслях больше на виду, а организаторы копнули в сторону «экзотики», поскольку были представлены системы водоснабжения, «умные» дома, железнодорожный транспорт, системы видеонаблюдения.

5. Нормативно-правовая основа кибербезопасности – 4 доклада

Презентации затрагивали, в основном, ФЗ-187.

6. R&D – 4 доклада

Речь в докладах шла о машинном обучении, о блокчейне, и, несколько неожиданно для меня, о MILS (Multiple Independent Levels of Security).

7. Человеческий фактор и управление персоналом – 2 доклада

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

8. Социологические аспекты кибербезопасности – 1 доклад

Был представлен доклад о влиянии масс медиа на общественное восприятие проблем кибербезопасности. Как и следовало ожидать, имеем много искажений реальности.

Как видим, покрытие тематики индустриальной безопасности достаточно широкое. Для меня, пожалуй, самым важным оказалась общая тенденция, которая явно прослеживается в докладах – в среде кибербезопасности есть определенное движение в сторону принятия и применения наработок в области функциональной безопасности. Видимо, в ISA в важности этого твердо убеждены, а они задают в этом тон всему миру. Остальные пока больше говорят, чем применяют что-то на практике. В итоге, многие вещи из области safety «открываются» для security заново (те же примеры – «заново открытые» HAZOP и MILS).

Из того, что не прозвучало на конференции (хотя, возможно, и могло бы прозвучать):
- не было ничего про вероятностную оценку кибербезопасности; возможно, или не добрались еще до этого специалисты по ИБ (хотя до HAZOP и MILS уже добрались), или это не очень актуально с практической точки зрения; с другой стороны, вероятность отказа функции ИБ было бы и можно, и нужно посчитать, это был бы аналог SIS (Safety Instrumented Function);
- не было подробных докладов о международной нормативной базе, лучших практиках и т.п.; наверно, или слишком «академично», или всем уже надоело.

Из небольших дополнений или предложений (это делают организаторы других конференций). Когда я пытался разложить «по полкам» 40 докладов, мне показалось, что было бы удобно для реферирования использовать короткий общий ключ. Можно сделать или сквозную нумерацию всех презентаций по порядку или нумерацию по секциям, например, пленарные доклады: Р1, Р2 и т.д., Business Track: BT1, ВТ2 и т.д. Это, конечно, не самое главное.

Самое главное – это заметные позитивные стороны конференции, а именно:
- хороший уровень конференции чувствуется даже дистанционно, поскольку выступило много «сильных» спикеров;
- программа конференции обеспечила всесторонний охват самых важных аспектов промышленной кибербезопасности без «перекосов» в ту или иную сторону;
- конференция получилась действительно международная, а то часто организуются «международные» конференции, куда случайно попадают несколько «иностранных консультантов»; в Сочи все было «по-честному»; хотя основная масса участников была из РФ, делать слайды на английском, чтобы зарубежные участники понимали, о чем идет речь – это хорошая практика, даже если речь в презентациях идет о ФЗ;
- как правило, организаторы конференции могут внести в программу сколько угодно своих докладов, и это порой вызывает определенные нарекания; докладов от «Лаборатории Касперского» было немало, но все они были объективно качественными, и они, скорее, повысили общий уровень конференции, чем наоборот.

Все получилось, спасибо организаторам за отличный ивент!


суббота, 8 сентября 2018 г.

О книге «Обеспечение безопасности АСУТП в соответствии с современными стандартами»


Как обеспечить функциональную составляющую безопасности систем управления? Чем отличается функциональная безопасность от информационной безопасности и кто из них «главнее»? Есть ли смысл в сертификации на соответствие требованиям стандартов? Своим опытом в решении этих и других вопросов я старался поделиться с сообществом, когда полтора года назад начал публиковать серию статей. За это время из серии статей сложилось нечто большее.

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

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

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

Данная книга представляет собой пошаговое руководство, описывающее полный процесс сертификации компьютерных систем управления (АСУ ТП и других) и их компонентов на соответствие требованиям стандарта Международной электротехнической комиссии (МЭК) 61508 «Функциональная безопасность электрических / электронных / программируемых электронных систем». Кроме МЭК 61508, книга поможет в понимании всего семейства производных стандартов по функциональной безопасности, включая IEC 61511 «Functional safety – Safety instrumented systems for the process industry sector», IEC 62061 «Safety of machinery: Functional safety of electrical, electronic and programmable electronic control systems», IEC 61513 «Nuclear power plants – Instrumentation and control for systems important to safety», ISO 26262 «Road vehicles – Functional safety», EN 50129 «Railway Industry Specific – System Safety in Electronic Systems», IEC 62304 «Medical Device Software».

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



Раздел 1. «Изучаем МЭК 61508 и определяем структуру требований» содержит краткое описание архитектур компьютерных систем управления (КСУ), для которых применимы требования к ФБ. К таким архитектурам относятся: встроенные системы, АСУ ТП, системы на базе технологии «интернет вещей». Рассмотрены риски, возникающие в процессе функционирования КСУ, а также перечень стандартов, содержащих требования к ФБ и направленных на снижение возникающих рисков. Далее проведен анализ структуры, концепции и терминологии стандартов серии МЭК 61508 и предложена гармонизированная структура требований к ИБ и ФБ.

Раздел 2 «Запускаем проект сертификации» является уникальным, поскольку он посвящен организационной составляющей сертификации КСУ и их программно-аппаратных компонентов на соответствие требованиям к ФБ. Эта тема не затрагивалась в известных публикациях по ФБ, а ведь именно тщательная подготовка к выполнению проекта является залогом его успешного завершения. В основу раздела положен апробированный в нескольких аналогичных проектах алгоритм действий при подготовке к проведению сертификации, включающий определение объекта сертификации, разработку концепции продукта, создание проектной инфраструктуры, разработку плана выполнения работ, а также установление контактов с организацией, проводящей независимую сертификацию. Особое внимание уделяется экономической модели, позволяющей определить смету затрат на выполнение проекта сертификации.

В разделе 3 «Формируем систему управления функциональной безопасностью» рассмотрена группа требований, относящихся к управлению ФБ, включая управление персоналом, выбор и оценивание инструментальных средств, оценивание ФБ и другие процессы.

Раздел 4 «Измеряем показатели функциональной безопасности» рассматривает аспекты количественного оценивания ФБ, как составляющую теории надежности. Атрибуты ИБ и ФБ, виды показателей ФБ и их заданные значения рассматриваются с позиции требований МЭК 61508. Рассмотрены методы расчета показателей ФБ, такие как структурные схемы надежности, деревья отказов, марковские модели, анализ видов, последствий и критичности отказов. Приведены примеры расчета показателей ФБ.

Раздел 5 «Изучаем и выбираем методы обеспечения функциональной безопасности» основан на перечне методов, приведенных в МЭК 61508. Методы разделены на организационные и технические. Рассмотрены требования МЭК 61508 к выбору методов для защиты от отказов аппаратных и программных компонентов.

В разделе 6 «Проектируем и реализуем жизненный цикл информационной и функциональной безопасности» рассмотрена группа требований, относящихся к структуре жизненного цикла и содержанию его этапов. Предложена единая структура жизненного цикла с точки зрения соответствия требованиям и к ИБ, и к ФБ. Для этапов жизненного цикла рассмотрены выполняемые действия, состав и структура выпускаемых документов, применяемые методы верификации и валидации, обеспечения и оценивания ФБ. Описан подход к выполнению трассировки требований. Данный раздел является центральным, поскольку он содержит алгоритм работ по выполнению проекта сертификации, связывающий в единое целое все разделы книги.

Раздел 7 «Учитываем требования к информационной безопасности» рассматривает особенности КСУ с точки зрения взаимосвязи процессов обеспечения ИБ и ФБ. Практическая направленность данного раздела заключается в оптимизации затрат на комплексное координированное обеспечение ИБ и ФБ, когда одни и те же методы применяются одновременно и для обеспечения ИБ, и для обеспечения ФБ.

Раздел 8 «Учитываем особенности программируемых логических интегральных схем» рассматривает применение ПЛИС в качестве компонентов КСУ, а также связанные с этим аспекты сертификации на соответствие требованиям к ФБ.

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

Раздел 10. «Оцениваем и обосновываем соответствие требованиям к информационной и функциональной безопасности при помощи методологии Assurance Case» посвящен методологии, которая позволяет собрать в единую систему все артефакты проекта сертификации и, таким образом, наиболее эффективно подтвердить соответствие требованиям к ФБ.

В Приложении «Онлайн курс «Функциональная безопасность компьютерных систем» содержатся ссылки на авторский канал YouTube, на котором размещены в виде плейлистов видеолекции, входящие в состав массового открытого онлайн курса (Massive Online Open Course, MOOC).

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

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

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

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

Как осуществлялась работа над книгой? В основу ее лег опыт, полученный за 20 лет работы, в первую очередь, в атомной энергетике, а также для аэрокосмической отрасли, нефтегазовой и угольной промышленности, железнодорожного транспорта, пожарной безопасности, тепловой энергетики. Результатом этой деятельности являются десятки успешно завершенных проектов по сертификации и лицензированию. Внедренные системы продолжают надежно и безопасно работать в Аргентине, Болгарии, Бразилии, Канаде, Франции, России и Украине.

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

Хочу поблагодарить коллектив издательства «Инфра-Инженерия» и его генерального директора, Кирилла Уварова, за быструю и качественную работу по публикации.

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

В заключении, желаю всем полезных книг и профессионального роста!

P.S. Ссылка на книгу на Лабиринт.ру

суббота, 27 мая 2017 г.

Онлайн курс «Функциональная безопасность компьютерных систем»

источник

Вашему вниманию предлагается статья о том, как был создан онлайн курс по тематике «Функциональная безопасность». Сервисы онлайн обучения располагают студийным оборудованием для записи высококачественного звука и видео. А если вдруг представить, что доступа у вас к подобным ресурсам нет, а учебный материал надо подготовить для использования в онлайн режиме? Автор решил поделиться собственным опытом и раскрыть следующие вопросы:
- мотивация или зачем и кому это надо;
- инструменты подготовки и записи;
- содержание Massive Online Open Course (MOOC) по функциональной безопасности;
- дальнейшие шаги по развитию продукта.

Мотивация: зачем это делалось?

Будучи вовлеченным в образовательный процесс, пришлось решать задачу дистанционного обучения студентов направления «Кибербезопасность» на кафедре компьютерных систем и сетей Национального аэрокосмического университета «Харьковский авиационный институт». Дистанционность эта образовалась по причине моей географической удаленности.

Были и другие мотиваторы. Хотелось попробовать силы в новой для меня технологии преподавания, и посмотреть, как это работает.

Еще была задача подготовить консалтинговые материалы для коллег из индустрии, с которыми приходится обсуждать вопросы сертификации. Порог входа «с нуля» в эту тематику порой оказывается достаточно высоким, а, просмотрев материалы, можно приобрести достаточный уровень знаний, чтобы начать работать в проекте по сертификации. Поэтому, изначально ставилась цель сделать курс проблемно-ориентированным, то есть направленным на решение практической задачи: подготовка к сертификации на соответствие требованиям МЭК 61508 (либо других подобных стандартов по функциональной безопасности).

Таким образом, слушатели курса получили весь набор преимуществ пользователей MOOC: слушаем небольшими информационными блоками, изучаем в удобное время, если что-то не поняли или пропустили, то «прокручиваем» повторно и т.п. Очень подходит для студентов старших курсов, которые уже хотят решить вопрос с трудоустройством, и объясняют этим пропуск занятий.

В предметной области ориентир был сделан, в первую очередь, на АСУ ТП, но затрагивались и другие архитектуры систем управления: встроенные системы, интернет вещей и промышленный интернет вещей (Industrial IoT or Industrial Internet Control Systems).

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

Еще одна особенность видеолекций состояла в том, что слайды представлены на английском, а аудио записано на русском языке. Предполагаю, что части аудитории может не понравиться подобный «тяни-толкай», но все же попытаюсь объяснить, что с переводом специфической терминологии на русский язык не все обстоит гладко. Смотрим, например, терминологию из МЭК 61508, часть 4. Validation (3.8.2) переводится как «подтверждение соответствия», и это не единственный пример.

Подготовка и запись курса

В ходе подготовительных мероприятий был прослушан онлайн курс на тему «MOOC про MOOC», благо, подобные материалы сейчас доступны во множестве. Многое из услышанного оказалось крайне полезным и подтвердило тезис о действенности онлайн обучения.

Затем был проведен обзор доступных (на начало 2017 года) ресурсов в сети, которые бы частично или полностью соответствовали тому, что планировалось сделать. Оказалось, что курсов в формате MOOC, посвященных ФБ, не существует, хотя по ИБ, например, их множество. Однако, студентам похожие дисциплины читают. Наиболее похожим оказался курс MIT System Safety (преподает профессор Nancy Leveson). Однако, на сайте MIT доступны лишь учебные материалы, поэтому этот курс не являет MOOC в полном смысле слова. Еще один идеологически близкий курс, Software Security Engineering, был обнаружен в программе Software Engineering Institute (SEI), преподает его Nancy Mead. Таким образом, гипотеза об уникальности записываемого материала была подтверждена, то есть, ниша для MOOC по функциональной безопасности оказалась свободна.

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

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

Вводный ролик был записан на видеокамеру в формате HD. Все остальные материалы записывались с демонстрацией слайдов и голосом за кадром, без появления лектора на экране.

Для захвата видео и звука использовалась программа oCam. Никаких хлопот с ее установкой и применением не возникало. Видео записывалось в формате ISO MPEG-4 в целях последующей обработки видеоредактором YouTube. Как оказалось, видеоредактор YouTube еще и несколько улучшает качество нестудийного звука.

Содержание MOOC «Функциональная безопасность компьютерных систем»

Курс включает шесть лекций или, в терминологии MOOC, шесть недель обучения.

Лекции выложены на канале YouTube в виде следующих плейлистов (содержание плейлистов-лекций показано на рисунке 1):
Лекция 1. Введение в функциональную безопасность
Лекция 2. Требования стандарта МЭК 61508
Лекция 3. Управление функциональной безопасностью
Лекция 4. Жизненный цикл функциональной и информационной безопасности
Лекция 5. Оценивание показателей функциональной безопасности
Лекция 6. Методы обеспечения функциональной безопасности



Рисунок 1. Структура MOOC «Функциональная безопасность компьютерных систем»

Самостоятельная работа студентов реализуется по четырем направлениям:
- ответ на контрольные вопросы (quiz);
- чтение рекомендованной литературы;
- при желании – изучение дополнительных материалов, превышающих объем программы;
- и, самое главное, – индивидуальный проект.

Индивидуальный проект является главным результатом изучения курса, где важно не только найти заранее известные ответы на контрольные вопросы, а, прежде всего, необходимо решить прикладную задачу, основанную на получаемых знаниях. Такой задачей является разработка собственного документа, охватывающего оценивание ФБ по направлениям, изучаемым в лекционном материале. Называется этот документ Assurance Case (или «обоснование безопасности» в смысловом, а не в прямом переводе). Разработка Assurance Case применяется в практике оценивания и сертификации ИБ (Security Case) и ФБ (Safety Case). В качестве объектов оценивания предлагаются компоненты АСУ ТП: контроллеры, исполнительные механизмы и датчики. Студентам выдается шаблон Assurance Case, и они его поэтапно заполняют, основываясь на материале каждой из лекции. Структура шаблона показана на Рисунке 2.



Рисунок 2. Структура индивидуального задания (Assurance Case), выполняемого в ходе изучения MOOC «Функциональная безопасность компьютерных систем»

Выводы

Запись MOOC является увлекательным занятием, которое требует серьезных временных инвестиций. У каждого своя скорость проговаривания текста и его написания. Мои оценки говорят о том, что тысячу знаков текста (это полстраницы формата А4 с 14-м шрифтом через полуторный интервал) можно озвучить приблизительно за одну минуту. То есть, например, для подготовки записи получасовой лекции надо написать приблизительно 30 тысяч знаков (15 страниц текста).

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

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

Работая над курсом, я почувствовал, насколько все-таки медленно возможности технологий осваиваются некоторыми вузами. А реалии таковы, что мало кому удается повлиять на этот процесс. Как говаривал Вильям Гибсон, “the future is already here – it’s just not very evenly distributed”.

Разумеется, что предлагаемый набор плейлистов YouTube пока не может считаться полномасштабным MOOC, и после пилотной версии продукта необходимо выполнить еще ряд действий по доводке, а именно:
- добавить анимационные заставки;
- перенести курс в среду разработки MOOC (рассматривается edX);
- разработать онлайн тесты;
- разместить курс на одной или нескольких платформах онлайн обучения;
- набрать и обучить группу;
- а также, в перспективе, записать англоязычный вариант курса.
Этим и займемся в ближайшее время.

среда, 3 мая 2017 г.

Функциональная безопасность компьютерных систем управления, часть 8. Методы обеспечения информационной и функциональной безопасности


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

Большинство методов может применяться, в том числе, и для обеспечения информационной безопасности в рамках концепции интегральной безопасности (safety & security) современных систем управления.

Набор анализируемых методов базируется на требованиях МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems). В части специфики обеспечения информационной безопасности АСУ ТП за основу взят NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security», рассмотренный в одной из предыдущих статей.

МЭК 61508: Методы и средства обеспечения функциональной безопасности


При выполнении сертификации на соответствие требованиям МЭК 61508 к тому или иному уровню SIL (Safety Integrity Level), важно продемонстрировать,  что, во-первых, в продукт заложен необходимый и достаточный механизм обеспечения функциональной безопасности (ФБ), а, во-вторых, что необходимый и достаточный набор методов обеспечения ФБ применялся в процессе разработки. Исходя из этого, условно разделим методы обеспечения ФБ на технические и организационные.

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

При этом, большинство методов являются комплексными, то есть, один и тот же метод в той или иной мере направлен на защиту и от случайных, и от систематических отказов.
Описание методов обеспечения ФБ содержится в МЭК 61508-7 «Методы и средства». Однако, чтобы разобраться в требованиях к применению того или иного метода, одной только части 7 недостаточно.

В части 2 МЭК 61508, которая посвящена обеспечению ФБ систем и аппаратных средств, и в части 3, содержащей требования к ПО, есть три существенных приложения, которые определяют методы и средства по защите от случайных и систематических отказов. Структура МЭК 61508 такова, что детально методы и средства описаны в части 7. Таким образом, требования к защите от отказов из частей 2 и 3 МЭК 61508 трассируются в описания методов и средств по обеспечению ФБ в части 7. Эта взаимосвязь представлена на Рисунке 1.



Рисунок 1. Структура методов обеспечения безопасности согласно МЭК 61508

Приложение А части 2 МЭК 61508 рассматривает контроль отказов аппаратных средств в ходе эксплуатации, причем подразумевается, что это могут быть как случайные, так и систематические отказы. Детальное описание методов защиты от случайных отказов содержится в Приложении А части 7 МЭК 61508. Методы защиты от случайных отказов разделены на категории, в зависимости от типа рассматриваемых аппаратных средств, например, электрические компоненты, электронные компоненты, процессорные модули, память и т.д.

Приложение В части 2 МЭК 61508 рассматривает методы защиты от систематических отказов аппаратных средств на протяжении жизненного цикла. Следует отметить, что МЭК 61508 рассматривает в качестве источников систематических отказов аппаратных средств ошибки проектирования, ошибки эксплуатации и внешние экстремальные воздействия (климатические, механические, радиационные и другие). Детальное описание соответствующих методов содержится в Приложении В части 7 МЭК 61508. Структура изложения методов защиты от систематических отказов аппаратных средств имеет свои особенности, например, в категорию B.1 General measures and techniques входят такие разные методы, как Project Management, Documentation, Separation, Diversity. Далее методы распределены по этапам жизненного цикла.

Приложение А части 3 МЭК 61508 содержит руководство по выбору методов разработки и тестирования программного обеспечения с целью достижения полноты безопасности. Детальное описание соответствующих методов содержится в приложении С части 7 МЭК 61508. Здесь в категории С.1 General вообще не описываются никакие методы. Далее методы распределены по категориям: требования и детальный дизайн, архитектурный дизайн, инструментальные средства и языки программирования, верификация и модификация, оценивание ФБ.

Чтобы проиллюстрировать изложение вышесказанного в МЭК 61508, рассмотрим простейшую таблицу, которая определяет методы, применяемые для обеспечения функциональной безопасности программного обеспечения на этапе разработки спецификации требований (см. Рисунок 2).



Рисунок 2. МЭК 61508-7, Table A.1 – Software safety requirements specification

Допустим, нас интересует уровень полноты безопасности SIL3. Те методы, которые в графе "SIL3" обозначены, как HR (Highly Recommended), должны обязательно применяться. Во всяком случае, сертифицирующему органу будет практически невозможно объяснить, почему не использовался тот или иной обязательно рекомендованный метод. Методы, обозначенные, как R (Recommended), могут применяться, однако, от них также можно обоснованно отказаться. С Таблицей А1 (SIL3) здесь все достаточно просто. Рекомендуется применение формальных методов, однако, приоритет применения полуформальных методов выше (Highly Recommended). Поэтому, если применяются полуформальные методы, то от формальных можно отказаться. Применение прямой и обратной трассировки также является обязательным (про трассировку требований уже было сказано в предыдущих публикациях). Применение программного обеспечения для поддержки трассировки и разработки спецификации является очевидным.

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

Организационные методы обеспечения информационной и функциональной безопасности


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

Управление проектами

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

Документирование

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

Жизнненный цикл ИБ и ФБ

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

Использование лучших практик и стандартов кодирования

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

Стандарты кодирования и лучшие практики определяют ряд соглашений (coding conventions), которые используются при разработке ПО в качестве требований к коду. Такие соглашения включают в себя правила наименования и комментирования, правила отступов и оформления кода, ограничения по сложности и т.д.

Распространенной практикой является так называемое защитное программирование, когда при возникновении какой-либо критической проблемы программное обеспечение завершает работу заранее предусмотренным образом, т.е. переводит систему в безопасное состояние.

Использование сертифицированных компиляторов и библиотек

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

Контроль качества при производстве аппаратных средств

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

Использование формальных и полуформальных нотаций

Еще одним организационным методом, требуемым МЭК 61508, является применение формальные и полуформальных нотаций для разработки спецификации требований и проектов систем, а также программных и аппаратных компонентов. В настоящее время наиболее распространенными полуформальными нотациями для проектирования программируемых систем являются IDEF и UML.
Для программируемых логических контроллеров разработаны и описаны в стандарте МЭК 61131-3 типовые языки программирования, поддерживаемые большинством сред разработки. Наиболее распространенным является графический язык FBD (Function Block Diagram), который фактически является формальной нотацией для проектирования программного обеспечения.

Технические методы обеспечения ФБ


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



Рисунок 3. Типовая архитектура АСУ ТП (источник: ISA/IEC 62443)

Резервирование

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



Рисунок 4. Дублирование компонентов АСУ ТП

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

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

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

Разнообразие (диверсность) при резервировании

Диверсностью (divercity) называется вид резервирования, когда в резервных каналах одна и та же функция выполняется разными путями, например, с применением разного оборудования или разного программного обеспечения.
Обычное резервирование не защищает от систематических отказов, вызванных ошибками проектирования. Поэтому, если версии системы спроектированы по-разному, то количество общих систематических отказов каналов (так называемых отказов по общей причине) снизится (во всяком случае, теоретически снизится). Это учитывается при помощи так называемого b-фактора, который показывает отношение количества отказов (или интенсивности отказов) по общей причине к общему количеству отказов (или интенсивности отказов). b-фактор зависит от применяемой стратегии диверсности. Чем больше  различие между каналами, тем ниже значение b-фактора (см. Рисунок 5).



Рисунок 5. Снижение количества отказов по общей причине при использовании различных (диверсных) дублированных каналов (источник: МЭК 61508)

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

Независимость и разделение компонентов

Еще одним методом, дополняющим резервирование, является принцип независимости и разделения (independency and separation) компонентов, направленный на предотвращение распространения отказов между системами и их компонентами. Разделение может быть физическим, когда, например, каналы системы физически находятся в разных помещениях или на значительном расстоянии друг от друга (см. Рисунок 6). Применяется также электрическое разделение, включающее, например, гальваническую изоляцию, а также функциональная независимость и независимость коммуникаций, например, экранирование кабелей и разделение электрических и сигнальных кабелей.




Рисунок 6. Физическая и электрическая независимость каналов (источник: МЭК 60709)

Самодиагностика

Самодиагностику цифровых устройств упрощенно можно описать следующим образом (см. Рисунок 7).



Рисунок 7. Реализация диагностики в системах управления

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

Watchdog контролирует простейший отклик от микросхем, выполняющих обработку данных, и при обнаружении проблемы (прекращении отклика) отключает питание и переводит систему в безопасное состояние. Кроме того, ватчдог может контролировать уровень питания и выдавать аналогичную команду на отключение при опасном отклонении питания от заданного уровня. Безопасное состояние для систем безопасности, как правило, заключается в снятии питания с выходных аналоговых и дискретных выходов. При необходимости, система безопасности может подавать питание на исполнительные механизмы, но тогда на выходе требуются дополнительные преобразователи сигнала.

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

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

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

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

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

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

Защита от воздействий окружающей среды

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

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

Специальные стандарты АТЕХ применяются для конструирования взрывобезопасных систем. Стандарты IP применяются для конструирования систем, защищенных от воздействия пыли и влаги.

Защита от ошибок персонала

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

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


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



Рисунок 8. Уязвимости в АСУ ТП (источник: Byres Research Inc.)

Такими уязвимостями являются: периметр сети, удаленные подключения, файрволы, приобретаемое оборудование, сменные носители информации (в первую очередь, использующие USB порты), а также программное обеспечение контроллеров и коммуникационные линии.

Сегментирование сети

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



Рисунок 9. Структура сети АСУ ТП с DMZ (источник: NIST 800-82)

Контроль доступа

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

Шкафы с оборудованием снабжаются замками и контактными датчиками открытия дверей, которые выдают сигналы на табло сигнализации.

Мониторинг и сохранение большого объема диагностических данных, в том числе, связанных с ИБ, предоставляет широкие аналитические возможности.

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

Для изменения настроек ПО и самого ПО, а также для изменения конфигурации аппаратных средств должна выполняться специальная авторизация.

Выводы


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

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

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

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

P.S. Данная статья завершает цикл публикаций на тему функциональной безопасности. Основной целью публикаций являлось знакомство с азами серии стандартов МЭК 61508 и подходам к сертификации систем управления на соответствие требованиям МЭК 61508. Параллельно публикациям был подготовлен и записан видеокурс по функциональной безопасности (аналогов в мире не имеет). Тема безопасности остается неисчерпаемой, и автор готовит новые публикации.