
- упрощение процесса создания и сопровождения сертификационной документации;
- декомпозиция ПО по разным уровням безопасности и сертификация их по отдельности;
- упрощение процесса взаимодействия с аудитором (оценщиком); этот вопрос выходит за рамки настоящего материала и поэтому более подробно не рассматривается.
Подход с декомпозицией по уровням безопасности стал набирать вес в последнее время в свете растущей тенденции к объединению разнородных вычислительных подсистем на единой аппаратной платформе (с целью сокращения массы, габаритов и потребляемой мощности). Поскольку к различным подсистемам при этом могут предъявляться различные требования по безопасности (как функциональной, так и информационной), в зарубежной терминологии для таких систем даже появился специальный термин – «системы смешанной критичности» (mixed criticality systems). Казалось бы, решая одну аппаратную проблему, с точки зрения ПО такой подход создаёт другую: в общем случае объединение на одной аппаратной платформе нескольких программных приложений различного уровня безопасности потребовало бы сертификации по самому высокому из требуемых уровней. Однако на настоящий момент уже существуют технологии, позволяющие разбить программную систему на независимые разделы и сертифицировать ПО этих разделов по отдельности (мы к этому ещё вернёмся). Как было показано ранее, с ростом требований к безопасности ПО объём необходимой сертификационной документации ощутимо растёт, но и критичного кода в системе обычно значительно меньше, чем некритичного, так что грамотное разбиение системы на разделы может дать существенную экономию трудозатрат.
Рассмотрим этот процесс подробнее, в частности, из чего состоит подлежащее сертификации ПО и где и как можно сэкономить.
Состав программного стека, и что из него следует

- прикладное ПО всегда специфично для конкретного проекта (хотя и может содержать унаследованный код), а также подвержено текучке требований, и поэтому меняется постоянно;
- пакет BSP всегда привязан к аппаратуре, и поэтому может быть специфичен для группы проектов, использующих одно и то же оборудование, то есть меняется редко;
- связующее ПО и аппаратно-независимая часть ОС могут применяться в различных проектах в коробочном виде, и поэтому в идеале не подвержены изменениям вообще (по крайней мере, до выхода следующей версии, на которую имеет смысл переходить).
«Ручной» подход
Самым распространённым подходом к разработке сертификационной документации (по крайней мере, в отечественной практике), к сожалению, является разработка и сопровождение сертификационной документации для всего программного стека вручную. Этот подход способен дать значительный выигрыш на первой итерации (особенно притягательными для высшего менеджмента обычно кажутся нулевые подготовительные затраты), но, увы, только на первой, так как, что уже обсуждалось, программный проект никогда не ограничивается одной итерацией. Каждое вносимое в проект изменение (особенно это касается уровня прикладного ПО) будет требовать множества связанных правок в пакете сертификационных документов. Это чревато не только катастрофическим разрастанием трудозатрат по мере взросления проекта, но и нарушением целостности сертификационного пакета из-за накопления человеческих ошибок, что неизбежно ведёт к проблемам в процессе подтверждения соответствия и в конечном итоге к переделыванию всей работы заново.Единственная часть программного стека, где определённая доля ручной работы не только оправданна, но и необходима, – это BSP. В частности, структурное тестирование BSP очень трудно поддаётся автоматизации, так как выполнение аппаратно-зависимого кода жёстко привязано к временны́м характеристикам оборудования, и инструментирование такого кода в автоматическом режиме может сделать его неработоспособным.
Купить нельзя построить: применение сертифицированных и сертифицируемых компонентов
Одним из способов сократить трудозатраты по созданию и сопровождению сертификационной документации является применение коммерческих (Commercial Off-The-Shelf – COTS) сертифицированных (или сертифицируемых – о разнице между этими понятиями уже говорилось ранее) программных компонентов.Смысл этого подхода в том, что некоторые части программного стека (например, ОС и связующее ПО) остаются неизменными достаточно долгое время, и вместо того чтобы разрабатывать и сопровождать их (а также сопутствующую сертификационную документацию) самостоятельно, может оказаться гораздо дешевле (а главное, быстрее) приобрести готовый коммерческий продукт, уже имеющий необходимый сертификат или снабжённый сертификационным пакетом. Это не отменит необходимости в подготовке сертификационной документации для остальных компонентов (например, BSP и прикладного ПО), но существенная часть работы будет сделана – по статистике компании Wind River, применение сертифицируемой ОС в сочетании с коммерческим сертификационным пакетом способно сократить трудозатраты на 2 человеко-года и более.
У этого подхода, правда, есть три тонкости.
Во-первых, поскольку требования безопасности налагают ограничения на архитектуру ПО, а стоимость сертификации напрямую зависит от объёма подлежащего сертификации кода, далеко не любой программный продукт является в принципе пригодным для сертификации. Чтобы пройти сертификацию, продукт должен быть разработан определённым образом, иметь определённое внутреннее устройство (в соответствии с требованиями нормативной базы, о чём говорилось ранее) и быть по возможности более компактным (чтобы стоимость сертификации не получилась неоправданно высокой). Этим, кстати, объясняется чрезвычайно низкий уровень присутствия ОС Linux в системах с высокими требованиями к функциональной безопасности – Linux без существенных доработок не проходит ни по требованиям стандартов, ни по стоимости сертификационных работ.
Во-вторых, не всякий пригодный к сертификации программный продукт имеет сертификаты (или сертификационные пакеты) по всем возможным стандартам функциональной и информационной безопасности – это было бы слишком дорого. Производители продуктов обычно сами решают, на каких рынках фокусироваться, и затем уже обеспечивают своим продуктам необходимую базу для отраслевой сертификации. Если продолжать говорить об ОС, то абсолютный чемпион в этом смысле из представленных в России – ОС Vx-Works компании Wind River, имеющая сертификационные пакеты DO-178B/C до уровня А включительно и МЭК 15408 до уровня EAL 6+ (согласно [5] версии 1.3), а также сертификат МЭК 61508 до уровня SIL 3 включительно. На базе сертификационного пакета МЭК 61508 для VxWorks в последние годы компанией Wind River был также выполнен ряд железнодорожных проектов с сертификацией по EN 50128 вплоть до уровня SIL 4. Почти аналогичный набор (за исключением DO-178B/C) есть у широко распространённой в России ОС QNX Neutrino, кроме того, её защищённая версия (ЗОСРВ КПДА 10964-01 «Нейтрино») также имеет отечественные сертификаты информационной безопасности в системах сертификации ФСТЭК и МО. Сертифицированные ОС на базе Linux (например, российская Astra Linux Special Edition) представляют собой противоположный экстремум – сертификаты информационной безопасности у них есть, а функциональной – нет.
В-третьих, применение коммерческих сертифицированных и сертифицируемых программных компонентов всегда сопряжено с оговорками, так как сертификация «сферического компонента в вакууме» – это одно, а интеграция его в сложную многокомпонентную систему – совсем другое. Также важен вопрос взаимного доверия оценщиков: стандарты функциональной и информационной безопасности говорят об этом разными словами, но практический смысл очень схож: наличие сертификата у коммерческого программного компонента ещё не гарантирует положительный вердикт оценщика, и может потребоваться повторная оценка. Хорошая новость, правда, заключается в том, что если есть сертификат, то есть и сертификационная документация, то есть повторную оценку безопасности не придётся делать с нуля, а значит, она обойдётся дешевле.
Ну и, естественно, данный подход работает только для компонентов программного стека, не подверженных частым изменениям (читай – ОС и связующего ПО). Для остальных компонентов приходится искать другие способы сокращения сертификационных трудозатрат.
Автоматизируй это: инструментарий верификации и валидации
Большинство методик обеспечения качества ПО, описанных в статье, являются в той или иной степени автоматизируемыми. То есть понятно, что нельзя автоматизировать процесс, скажем, написания тестов, но процесс генерации «обёртки» (test harness) и входных данных для тестирования автоматизировать можно. Также можно автоматизировать процесс статического анализа, а его выходные результаты, в свою очередь, автоматически подать на вход процесса анализа структурного покрытия, и так далее. Потом по результатам выполнения всех необходимых задач можно автоматически сгенерировать отчёт, оформленный в соответствии с требованиями нужного стандарта, и подшить его к сертификационной документации. Основная ценность такого подхода в том, что он позволяет, однажды настроив процесс генерации документов, повторять его по необходимости в автоматическом режиме. Это обеспечивает непрерывную целостность сертификационного пакета и предохраняет от человеческих ошибок.В литературе, посвящённой качеству ПО, постоянно фигурируют два термина – «верификация» (verification) и «валидация» (validation). Их часто путают друг с другом, в основном благодаря тому, что их классические определения безобразно неоднозначны, и поэтому разные источники относят к ним различные конкретные действия (например, в терминах DO-178B почти все описанные в настоящей статье методики относятся к верификации). Впрочем, хорошая новость заключается в том, что эти термины почти всегда употребляют вместе (видимо, чтобы не попасть впросак), поэтому достаточно сказать «верификация и валидация» (V&V) – и точно не ошибёшься.
Так вот, существует целый класс программных продуктов, автоматизирующих задачи V&V, их так и называют – инструменты верификации и валидации (verification and validation tools). К таким инструментам относятся средства статического анализа, анализа покрытия (ряд производителей встраиваемых ОС даже включает их в дистрибутив комплекта разработчика), автоматизированного тестирования и т.п. Количество таких инструментов на рынке исчисляется десятками; однако каждый из них решает только свою часть задачи, поэтому основная цель – поддержание целостности сертификационной документации – в случае использования разрозненных инструментов не достигается. К тому же разрозненные инструменты зачастую не привязаны к конкретным стандартам, а значит, следить за тем, чтобы созданные сертификационные документы содержали подтверждение выполнения всех нормативных требований, в этом случае тоже нужно вручную.
Гораздо более привлекательным вариантом, с точки зрения снижения стоимости разработки и сопровождения сертификационной документации, являются интегрированные программные пакеты, изначально ориентированные на решение задач подтверждения соответствия. Хороший пример такого пакета – LDRA Tool Suite компании LDRA, содержащий готовые решения по подготовке сертификационной документации согласно DO-178B/C, МЭК 61508, EN 50128, МЭК 26262 и МЭК 62304 (а в ближайшей перспективе ещё и МЭК 60880). В состав пакета входят:
- шаблоны и примеры проектов подтверждения соответствия по всем поддерживаемым стандартам. Иными словами, любой проект в LDRA Tool Suite всегда начинается с выбора целевого стандарта, соответствие которому нужно продемонстрировать, из этого сразу следует актуальный список конкретных задач;
- средства интеграции с системами управления требованиями и трассировки требований (рис. 3).
Задача управления требованиями выходит за рамки компетенции LDRA Tool Suite, для этого существует отдельный класс программных продуктов (например, популярная в авиации система IBM Rational DOORS). Однако, поскольку для подтверждения соответствия нужно демонстрировать привязку кода и тестов к требованиям, степень покрытия требований тестами и т.п., LDRA Tool Suite умеет импортировать требования из внешних источников (они, к слову, могут быть любыми, хоть документами Microsoft Office) и настраивать и поддерживать необходимые информационные связи между требованиями разного уровня и остальными проектными документами. Когда затем что-то в проекте меняется (требования, код, тестовые процедуры и т.п.), LDRA Tool Suite уведомляет пользователя, какие из связанных документов затрагиваются внесёнными изменениями и требуют обновления. Кроме поддержания целостности, эта функция играет ещё одну важную роль – она позволяет оценить стоимость изменений, так как наглядно демонстрирует, какой объём работы придётся реально выполнить, чтобы внести, с первого взгляда, незначительную точечную правку; - средства интеграции с системами управления конфигурацией (контроля версий). Поскольку стандартами безопасности ПО предписывается необходимость контроля версий проектных документов, документы обычно хранятся в централизованном репозитории, организованном с помощью одной из автоматизированных систем контроля версий (version control), – CVS, SVN, Perforce, SourceSafe и т.п. Пакет LDRA Tool Suite поддерживает интеграцию с этими системами, что упрощает его подключение к существующей ИТ-инфраструктуре; в свою очередь, использование автоматизированной системы контроля версий позволяет быть уверенным в корректности входных данных и облегчает трассировку;
- средства статического анализа, в том числе подсчёта метрик, построения графов вызовов и подтверждения соответствия стандартам кодирования (рис. 4).
В процессе статического анализа, кроме проведения необходимых проверок исходного текста и расчёта его количественных характеристик, формируется граф внутренней структуры ПО и взаимосвязи модулей, который затем используется как входная информация для тестирования и анализа покрытия; - средства автоматизированного тестирования, включая автоматическую генерацию «обёртки» и массивов входных данных (в т.ч. граничных и случайных значений) для программных модулей, анализ структурного покрытия и тестирование на целевой системе (рис. 5); необходимые режимы и глубина тестирования определяются применимыми стандартами;
- средства командной работы с распределением ролей. Подтверждение соответствия включает в себя множество задач, в общем случае выполняемых разными людьми (а зачастую эти люди ещё и обязаны быть разными согласно нормативным требованиям). LDRA Tool Suite позволяет распределить задачи между соответствующими исполнителями и централизованно контролировать процесс;
- система генерации отчётов в настраиваемом формате. Выполнение предписанных выбранным стандартом процедур V&V – это ещё не всё: все полученные результаты нужно ещё представить в удобочитаемой форме для предъявления оценщику в составе сертификационной документации. Встроенный генератор отчётов LDRA Tool Suite позволяет экспортировать результаты в документы настраиваемого формата, а также автоматически генерировать сложные кросс-отчёты, например матрицу трассировки.
У этого подхода, правда, тоже есть одна тонкость: чтобы оценщик признал результаты V&V, полученные с использованием инструментального пакета, этот инструментальный пакет должен предварительно пройти так называемую квалификацию (qualification), чтобы подтвердить, что генерируемые им результаты корректны. Квалификация может производиться третьей стороной, поэтому важно, чтобы оценщик, работающий с сертификационной документацией, созданной с помощью инструментального пакета, признал его квалификацию. В общем случае оценщик может потребовать повторной независимой квалификации инструментального пакета (например, квалификация инструментальных средств, выполненная зарубежными оценщиками, в России может не признаваться), и чтобы сделать это возможным, производители инструментальных пакетов V&V предоставляют для своих продуктов пакеты квалификационной документации.

Разделяй и властвуй: IMA, MILS и виртуализация
Вычислительная мощность и функциональные возможности современных процессоров позволяют им выполнять несколько приложений одновременно, и если с точки зрения сокращения массогабаритных характеристик и потребляемой мощности это однозначно плюс, то с точки зрения стоимости сертификации, на первый взгляд, всё совсем наоборот. Дело в том, что, как уже упоминалось, объём работ по подтверждению соответствия сильно зависит от уровня безопасности (как функциональной, так и информационной), по которому производится сертификация, а критичного кода в системе часто значительно меньше, чем некритичного. Объединение на одном процессоре нескольких приложений разной степени критичности требует сертификации всех этих приложений по максимальному среди них уровню безопасности, а значит, суммарные трудозатраты резко возрастают. Или нет?
Разделы получают процессорное время по определённому графику, то есть тоже подвержены планированию, иными словами, планировщики ОС VxWorks 653 и VxWorks MILS также являются двухуровневыми: с одной стороны, гипервизор планирует разделы, с другой, гостевые ОС разделов планируют потоки своих приложений, когда их раздел активен.

В рамках данной концепции гипервизор подлежит сертификации по самому высокому из требуемых уровней безопасности, зато гостевые ОС и приложения разделов могут сертифицироваться по уровню не выше требуемого. В результате удаётся, объединив на одном процессоре несколько приложений с различными требованиями к безопасности, одновременно сэкономить на массе, габаритах и энергопотреблении, и, как минимум, не увеличить стоимость сертификации (а при грамотном распределении кода по разделам безопасности и дополнительно сократить её).
Забегая немного вперёд, дополнительно надо отметить, что в системах смешанной безопасности, не относящихся к IMA и поэтому не подпадающих под требования спецификации ARINC 653, реализация временно́й изоляции разделов обязательной не является – достаточно обеспечить пространственную изоляцию. Это упрощает создание виртуализированных систем смешанной безопасности на базе многоядерных процессоров, но об этом будет сказано позже.
В четвёртой, заключительной части статьи рассматриваются примеры решений на основе коммерческих (COTS) компонентов и возможные перспективы развития технологий безопасности ПО. ●
Литература
- DO-178B&DO-254 White Papers [Электронный ресурс] // Режим доступа: http://www.highrely.com/whitepapers.php.
- DO-178 Industry Group for Engineers [Электронный ресурс] // Режим доступа: http://www.do178site.com/
- Christian Hagen, Jeff Sorenson. Delivering military software affordably // Defense AT&L. – 2013. – March–April.
- LDRA Certification Services [Электронный ресурс] // Режим доступа: http://www.ldra.com/en/services-support/certification-services.
- U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness. – USA: Information Assurance Directorate, 2007.
- Паркинсон Пол. Многоядерные вычислительные среды и безопасность ПО. Часть 1 // Современная электроника. – 2013. – № 8.
фирмы ПРОСОФТ
Телефон: (495) 234-0636
E-mail: info@prosoft.ru
Если вам понравился материал, кликните значок - вы поможете нам узнать, каким статьям и новостям следует отдавать предпочтение. Если вы хотите обсудить материал - не стесняйтесь оставлять свои комментарии : возможно, они будут полезны другим нашим читателям!