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

на два лагеря: авиация и всё остальное. В авиации (в том числе беспилотной – [1], п. 6.1) господствует стандарт RTCA DO-178В, сейчас постепенно заменяе- мый новой версией DO-178C (квалифи- кационные требования КТ-178B и КТ- 178С в российской версии соответствен- но); в АСУ ТП, атомной энергетике, ав- томобилестроении, железнодорожном транспорте и прочих критичных отрас- лях основой являются IEC 61508 и его производные (IEC 60880, 26262, 62279 и т.д.) – большая часть их переведена на русский язык и имеет статус государст- венных стандартов РФ (табл. 1). Космонавтика в этой картине дер- жится особняком, и требования функ- циональной безопасности, предъявляе- мые к космическим проектам, могут ос- новываться на различных стандартах (а порой и на их комбинации), в зависи- мости от конкретного случая. В таблице 1 есть два очевидных белых пятна, и если отсутствие в отечествен- ной нормативно-технической базе ана- лога IEC 26262 традиционно не вызыва- ет удивления (все, наверное, видели ка- рикатуру, на которой манекен для краш- тестов упирается из последних сил, ста- раясь не дать инженеру АвтоВАЗа поса- дить себя в LADA Priora), то на ситуации с железнодорожной отраслью имеет смысл остановиться чуть подробнее. В настоящий момент отечественная нормативно-техническая база функ- циональной безопасности ПО на же- лезнодорожном транспорте имеет вид дырявого лоскутного одеяла. Техниче- ские регламенты Таможенного союза [2] «О безопасности железнодорожного подвижного состава» (ТР ТС 001/2011), «О безопасности высокоскоростного железнодорожного транспорта» (ТР ТС 002/2011) и «О безопасности инфра- структуры железнодорожного транс- порта» (ТР ТС 003/2011), вступившие в силу в августе 2014 года, картину не проясняют, так как программные сред- ства в них явно указаны в числе состав- ных частей, подлежащих сертификации с предварительной разработкой об- основания безопасности (читай: серти- фикационного пакета, о котором сказа- но ранее), но в указанных в [2] перечнях стандартов ссылки на нормативно-тех- ническую базу функциональной без- опасности ПО напрочь отсутствуют. Надежду на скорое изменение ситуа- ции к лучшему, впрочем, вселяет «Транс- портная стратегия РФ на период до 2030 года» [3], в числе целей которой заявле- ны интеграция в мировое транспортное пространство и реализация транзитного потенциала страны и повышение уровня безопасности транспортной системы. Одним из важных шагов к реализации этих целей является начало масштабно- го внедрения в российской железнодо- рожной отрасли международного стан- дарта качества IRIS, явно содержащего требования к безопасности ПО и ссы- лающегося по этой части на стандарт EN 50128 (он же IEC 62279). В настоящее время ведутся работы по созданию рос- сийского аналога EN 50128, причём у отечественной версии есть все шансы оказаться лучше своего зарубежного ро- дителя, так как за годы использования EN 50128/IEC 62279 у зарубежных кол- лег накопилась ценная обратная связь, и грех этим не воспользоваться. И НФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ Сразу оговоримся, что в данном раз- деле речь идёт только о системе серти- фикации Федеральной службы по тех- ническому и экспортному контролю (ФСТЭК), под юрисдикцию которой подпадают технические средства защи- ты информации (СЗИ) некриптографи- ческими методами. Системы сертифика- ции Федеральной службы безопасности России и Министерства обороны РФ в силу ограниченной доступности своих нормативно-методических документов в настоящей статье не затрагиваются. Основой российской нормативно-тех- нической базы информационной без- опасности в системе сертификации ФСТЭК являются руководящие доку- менты (РД) ФСТЭК, те из них, которые были выпущены до 2005 года, также из- вестны как РД Гостехкомиссии (ФСТЭК была создана на её базе в 2005 году). В мировом сообществе, в свою очередь, основным на текущий момент стандар- том в области информационной безопас- ности является IEC 15408 (так называе- мые «Общие критерии» – фактически метастандарт, задающий систему поня- тий, в рамках которой можно единооб- разно описывать требования информа- ционной безопасности) и связанные с ним IEC 18045 и 19791. На этом обзор нормативной базы можно было бы и за- кончить, если бы не одно «но». Необходимость приведения россий- ской нормативной базы информацион- ной безопасности в соответствие между- народным требованиям, вызванная вступлением России в ВТО, послужила основанием для перевода стандартов IEC 15408, 18045 и 19791 на русский язык и получения ими статуса государственных стандартов РФ (ГОСТ Р ИСО/МЭК 15408, 18045 и 19791 соответственно). Кроме того, принятие «Общих критери- ев» сулило ещё один плюс: развитие се- тевых технологий за последние десятиле- тия привело к тому, что современные средства вычислительной техники (СВТ) и автоматизированные системы (АС) пе- рестали укладываться в классификацию, приведённую в традиционных РД ФСТЭК, разработанных в 1990-х годах, в связи с чем возникла необходимость в унифицированной основе для разработ- ки новых нормативно-методических до- кументов. «Общие критерии» как раз предоставляли такую основу. Однако, несмотря на вступление ГОСТ Р ИСО/МЭК 15408 в силу еще в 2004 году, немедленного широкомас- штабного перехода на «Общие критерии» в России не произошло, как минимум, потому что сами по себе «Общие крите- рии» проблему не решают, они лишь пре- доставляют единый каркас для норма- тивных документов, содержащих кон- кретные требования к объектам оценки (ОО). Таким образом, переходить нужно не на сам стандарт, а на нормативные до- кументы, созданные на его основе, а их ещё надо разработать. В рамках «Общих критериев» пред- усматривается два типа таких доку- ментов. ● Профиль защиты (ПЗ, англ. Protection Profile) содержит набор требований без- опасности к определённому классу ОО. ● Задание по безопасности (ЗБ, англ. Security Target) описывает требования к конкретному ОО; если ОО принад- лежит к одному или более утверждён- ных классов, ЗБ будет ссылаться на соответствующие ПЗ. В свою очередь, требования безопас- ности, содержащиеся в этих докумен- тах, делятся на две категории. ● Функциональные требования безопасно- сти (не путать с требованиями функ- циональной безопасности!), то есть что нужно реализовать в продукте для достижения заданных целей безопас- ности. ● Требования доверия , то есть как этот продукт следует разрабатывать, экс- плуатировать и оценивать, чтобы быть уверенным, что заданные функцио- нальные требования реализованы кор- ректно. Степень этой уверенности вы- ражается так называемым оценочным уровнем доверия (ОУД, англ. Evaluation Assurance Level, EAL): чем выше тре- буемый ОУД (всего их определено 7), ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ 17 СТА 1/2015 www.cta.ru