ЖУРНАЛ СТА 3/2015

36 СТА 3/2015 ОБЗОР /ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ www.cta.ru Чтобы не создавать впечатление ана- литического паралича, самое время приостановить анализ и перейти к син- тезу. Допустим, в ТЗ написано: подле- жит сертификации по такому-то стан- дарту, уровень безопасности такой-то. Что можно с этим сделать, чтобы уло- житься в сроки и бюджет? Вспоминая приведённую в третьей части статьи структуру программного стека, проведём границу между ОС и прикладным ПО – это разделит вопрос на два, смысл такого разделения будет ясен чуть позже. П ОДГОТОВКА К СЕРТИФИКАЦИИ СИСТЕМНОЙ ПЛАТФОРМЫ Первое, с чего следует начать на уров- не системной платформы (то есть связ- ки оборудования и ОС) – это понять, что в ней проще сделать своими сила- ми, а что лучше купить (так называемая дилемма “Build vs. Buy”). При прочих равных условиях купить всегда проще, но с сертифицируемыми компонентами ситуация усложняется, так как они яв- ляются товаром скорее штучным, чем массовым, и найти подходящую комби- нацию не всегда физически возможно. К примеру, функционально безопас- ные многоплатформенные ОС могут быть реально доступны всего для еди- ниц моделей процессоров (да ещё и не в любой версии), и если выбирать про- цессор без оглядки на ОС, то можно по- пасть в неловкую ситуацию, когда обо- рудование уже есть, а ОС для него нет и не предвидится. С BSP (board support package – пакет поддержки оборудова- ния) похожая история: готовых серти- фицируемых BSP не так много, и надо быть готовым к тому, что подходящая ОС будет поддерживать только сам про- цессор, а сертифицируемые драйверы периферийных устройств придётся раз- рабатывать самостоятельно. Аналогич- но с пакетами сертификационной доку- ментации: они могут быть доступны не для всех стандартов, не по всем воз- можным уровням безопасности и не для всех комбинаций версии ОС и процес- сора (высокие уровни безопасности мо- гут требовать трассировки требований до объектного кода, а значит, сертифи- кационные пакеты для ОС на разных процессорах могут отличаться). Это значит, что даже если сертификацион- ный пакет доступен, он не обязательно будет пригоден «из коробки» – может потребоваться доработка. Иными словами, зная стандарт, по которому будет проводиться сертифи- кация, и требуемый уровень (уровни) Николай Горбунов В статье приводится обзор современной терминологической и нормативно-технической базы функциональной и информационной безопасности ПО, затрагивается ряд основополагающих вопросов качества ПО и их привязка к нормативной базе. Рассматриваются примеры программных продуктов, соответствующих современным требованиям сертификации, и практические подходы к подтверждению соответствия. В четвёртой, заключительной, части приводятся практические примеры на базе существующих коммерческих решений и затрагиваются возможные перспективы развития технологий безопасности ПО. Безопасность и сертификация программного обеспечения Часть 4. Примеры и перспективы Таблица 1 Пример матрицы доступности (PAM) ОС Версия Сертификационные пакеты Уровни безопасности Поддерживаемые процессоры BSP Примечания ОС 1 1.2.3 DO-178C A,B,C,D Процессор 1 Плата 1 Отладочная Плата 2 Процессор 2 Плата 3 МЭК 61508 SIL 3, 4 Процессор 3 Плата 4 4.5.6 EN 50128 SIL 3 Процессор 4 – ОС 2 7.8.9 МЭК 60880 SIL 2, 3 Процессор 5 –