Формирование встроенной системы безопасности ИТ

Напрасно мирные забавы

Продлить пытаетесь, смеясь.

Не раздобыть надежной славы,

Покуда кровь не пролилась.

 

И как ни сладок мир подлунный,

Лежит тревога на челе –

Не обещайте деве юной

Любови вечной на земле.

Б. Окуджава

 

 

Илья Лившиц, доцент кафедры БИТ, Университет ИТМО, к. т. н., г. Санкт-Петербург	Андрей Неклюдов, независимый эксперт в области безопасности, г. Санкт-Петербург

 

 

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

 

Дела давно минувших дней

Для того чтобы пояснить свою позицию, авторы предлагают читателям краткий экскурс в историю вопроса безопасности информационных технологий (ИТ). В 2018 г. исполняется 40 лет официального представления в 1978 г. инициативы The Department of Defense (DoD[1]) Computer Security Initiative, которая впервые в мире поставила в качестве основной цели достижение повсеместного наличия доверенных компьютерных систем (КС). Под термином «доверенная» подразумевалось наличие в системе достаточного функционала безопасности, позволяющего одновременно обрабатывать как классифицируемую[2], так и прочую чувствительную информацию. Под «повсеместным наличием» подразумевалась безусловная доступность на открытом рынке компонентов, предназначенных для создания доверенных КС. В обиход даже было включено понятие «безопасность с полки» (off-the-shelf). Доверенные системы должны были быть пригодны для безопасной обработки разнородной чувствительной информации в многозадачном и многопользовательском режиме.

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

История инициативы Министерства обороны США (МО) уходит в начало 70-х гг. в ХХ в., когда National Institute of Standards and Technology (NIST) (до 1988 г. National Bureau of Standards) совместно с RAND Corporation и MITRE Corporation приступил к изучению вопроса безопасности КС. Побудительным мотивом к изучению данного вопроса помимо естественной потребности вооруженных сил США в обеспечении безопасности информации стала неудовлетворенность сложившейся практикой автоматизации их деятельности. В те годы на рынке автоматизации вооруженных сил США безраздельно господствовали IBM и еще, как тогда говорили, «пять гномов», а если с учетом компаний RCA и General Electric, то и «семь гномов». Стив Джобс отнюдь не был первым перфекционистом в области ИТ, IBM и «гномы» в бесконечном поиске совершенства уверенно снабжали вооруженные силы США множеством уникальных и несовместимых между собой КС. Довольно обычным явлением было, когда вместо тиражирования для сходных задач уже однажды примененной КС, начинали разработку очередной уникальной КС с «абсолютного нуля», т. е. с системы машинных команд. Это был вертикальный рынок КС, отягощенный еще и тем, что вертикальные границы пролегали не только между продуктами различных компаний, но и между различными продуктами одной компании.

Успешной реализации инициативы МО придавалось настолько большое значение, что сотрудники министерства, задействованные в обеспечении инициативы, очень плотно взаимодействовали с самым широким спектром молодых представителей индустрии ИТ, не ограничиваясь «старой гвардией». Достаточно сказать, что даже директор Агентства национальной безопасности (АНБ) генерал-лейтенант Линкольн Фаурер (Lincoln D. Faurer) минимум три раза в период с 1982 по 1983 г. выступал перед представителями индустрии ИТ, приглашая их к сотрудничеству и доводя до них позицию структур, уполномоченных на реализацию инициативы МО. Через некоторое время инициатива МО стала приносить первые плоды: 1 февраля 1982 г. компанией Intel был выпущен микропроцессор 80286, в котором был достаточно гармонично реализован набор функций безопасности, широко обсуждавшийся с 1979 по 1981 г. организациями, вовлеченными в реализацию инициативы, на регулярных семинарах – Seminar on the DoD computer security initiative program [1–3].

 

TCSEC

В 1983 г. начало очередного семинара совпало с подписанием меморандума о документе Department of Defense Trusted Computer System Evaluation Criteria[3] (TCSEC) (Memorandum I-12027/83 15 November 1983). В меморандуме содержалась весьма интересная формулировка, которая может быть переведена на русский таким образом: «…настоящим я разрешаю и поощряю использование прилагаемого документа о критериях оценки для выполнения ваших обязанностей, возложенных на вас ссылками (a) и (b) на временной основе до полной официальной координации документа». Из материалов семинара известно, что по поводу сути предложений, содержащихся в инициативе МО США, у участвующих сторон имелись, скажем так, очень разные, зачастую полярные мнения. Некоторое количество участников, в основном из «старой гвардии», ратовало за сохранение устоявшихся подходов к созданию компьютерных систем, возможно, с минимальными, «косметическими» изменениями. Вероятно, упомянутая формулировка была включена в меморандум в целях придания дополнительного импульса реализации инициативы МО в сложившихся обстоятельствах. В МО придавали настолько большое значение наличию адекватных критериев оценки безопасности, что без всяких предварительных условий были готовы вносить коррективы в TCSEC. Выступая на семинаре, директор центра компьютерной безопасности АНБ Мелвил Клейн (Melville H. Klein) сказал: «Мы осознаем их (TCSEC) ограничения и готовы адаптировать их с учетом технологических прорывов и меняющихся потребностей».

После 1983 г. МО и АНБ разработали целую серию документов, объединенную одной темой – доверенные КС, известную как «радужная серия». Последняя из известных авторам книг серии датирована 1995 г. По некоторым данным, высота стопки книг «радужной серии» составляла около 1,8 м. При достаточно широком охвате различных аспектов безопасности информации для всех сторон, вовлеченных в инициативу МО, вскоре стали заметны недостатки, затруднявшие использование «радужной серии» в качестве инструмента оценки безопасности перспективных ИТ. В частности, можно отметить следующие.

• Во-первых, в TCSEC критерии отнесения КС к конкретному классу не были определены с той степенью прозрачности и универсальности, которая позволяла бы легко и естественно использовать TCSEC для классификации как правительственных, так и коммерческих компьютерных систем. И если для МО это, судя по всему, не было проблемой, ведь при разработке TCSEC с высокой вероятностью ее разработчики ориентировалась на внутренние регламенты МО, то для открытого рынка отсутствие прозрачности критериев классификации КС значительно обесценивало TCSEC.
• Во-вторых, создатели TCSEC не смогли с требуемой точностью предугадать тенденции развития ИТ, а создаваемые в дальнейшем документы «радужной серии» также не были приведены в соответствие с существующим на тот момент уровнем развития ИТ, вероятно, не в последнюю очередь из соображения сохранения преемственности с системой взглядов, лежащих в основе TCSEC. Таким образом, оказалось, что в силу ряда причин «радужная серия» имеет ограниченные возможности по адаптации к изменяющимся обстоятельствам. Складывается впечатление, что под «компьютерной системой» разработчики «радужной серии» вплоть до самого последнего документа подразумевали «облик» КС по состоянию максимум на 1982 г. и так не смогли в необходимой степени понять и оценить степень изменения «облика» ИТ.
• В-третьих, несмотря на то что в документах «радужной серии» иногда встречается слово «риск», ни отдельные документы, ни вся серия в целом не является, к сожалению, примером риск-ориентированного подхода к оценке безопасности ИТ. А ведь в те годы риск-ориентированный подход уже широко использовался в различных отраслях рынка.

 

ITSEC

Несмотря на имеющиеся недостатки «радужная серия», безусловно, внесла выдающийся вклад в развитие оценки безопасности ИТ. Тогда, в 80-х гг. годах прошлого века, надо было с чего-то начинать, и в этом смысле «радужная серия» была не самым плохим стартом. Во многом благодаря ей в 1990 г. как реакция на TCSEC в Европе был создан документ Information Technology Security Evaluation Criteria (ITSEC). В 1984 г. инициатива МО принесла сразу два практических плода. Компания Gemini Computers, Inc. сообщила о разработке ею на базе микропроцессора Intel 80286 компьютера, предназначенного как для военного, так и для гражданского сектора. Дизайн и подходы к разработке операционной системы Gemini Multiprocessing Secure Operating System (GEMSOS) отвечали требованиям класса B3 TCSEC. Компания Intel представила микропроцессор Intel 80386, в котором на кристалле было реализовано устройство страничного преобразования, охваченное функциями безопасности, которые были сопряжены с функционалом безопасности, унаследованным от микропроцессора Intel 80286. Микропроцессоры Intel и далее из поколения в поколение будут приобретать новые функции безопасности, но во всех базовый функционал безопасности будет аналогичен функционалу безопасности Intel 80386.

В августе 1985 г. компании IBM и Microsoft начали разработку операционной системы (ОС) OS/2, в рамках которой фактически осуществлялась отработка механизмов обеспечения безопасности при вытесняющихся многозадачности и многопоточности. В октябре 1988 г. Дайв Катлер по приглашению Билла Гейтса переходит из компании DEC в Microsoft, где приступает к разработке многопользовательской многозадачной многопоточной ОС, впоследствии ставшей известной как Windows NT, функционал безопасности которой изначально задумывался соответствующим классу C2 TCSEC. В 1990 г. компания Gemini Computers, Inc. сообщила о разработке ею соответствующего классу A1 TCSEC Gemini Trusted Network Processor на базе восьми процессоров на выбор – либо Intel 80286, либо Intel 80386 и ОС GEMSOS. Таким образом, к 1990 г. в индустрии ИТ обозначились компании, которые связывали свое будущее с рынком продуктов ИТ и в необходимости насыщать эти продукты функционалом безопасности видели отнюдь не досадную помеху, а возможность получения осязаемых конкурентных преимуществ. Стало понятно, что в технической области инициативы МО вполне реализуемы. Но вот в нормативной области состояние дел было менее оптимистичным. Объем «радужной серии» увеличивался, но это, к сожалению, не переходило в сколько-нибудь ощутимую положительную тенденцию. ИТ и «радужная серия» жили и развивались вне взаимосвязи друг с другом. И это была проблема не ИТ, у которой были положительные тенденции, а «радужной серии», у которой таковые отсутствовали.

Поэтому, когда в 1990 г. на National Computer Security Conference [4], заменившей прежние регулярные семинары, были представлены ITSEC, у сторон, вовлеченных в инициативу МО США, не возникло никаких сомнений относительно целесообразности рассмотрения нового подхода для оценки безопасности ИТ, а АНБ не только проявило ранее обещанную гибкость подходов, но и выразило заинтересованность в заимствовании всего положительного из ITSEC. Надо отметить, что в ITSEC содержался ряд весьма удачных идей.

• Во-первых, ITSEC представлял единый набор гармонизированных критериев для оценки любых объектов ИТ. И это было значительное продвижение вперед по сравнению с TCSEC, для которых декларировалась возможность применения для любых объектов «компьютерных систем», но на практике они более или менее подходили только для оценки безопасности компьютеров, да и то участники открытого рынка были настроены довольно пессимистично относительно использования для этих целей TCSEC. При применении ITSEC каждый потребитель сам определял объект оценки (ОО) и сопоставлял ему набор критериев.
• Во-вторых, в ITSEC предусматривалось для ОО определять цели безопасности и предположения безопасности. Цели безопасности определяли набор функционала безопасности ОО, а механизмы безопасности − параметры среды функционирования ОО. В зависимости от требуемого уровня оценки цели безопасности могли излагаться на неформальном, полуформальном или формальном языке[4].
• В-третьих, в ITSEC предусматривалась оценка безопасности ИТ в разрезе двух показателей: функциональных критериев безопасности и критериев доверия к безопасности. Создателями ITSEC был очень верно подмечено, что для конкретного ОО необходимый набор функций безопасности зависит скорее от характеристик ОО, а не от ценности обрабатываемой им информации. А вот набор критериев доверия к безопасности, наоборот, в большей мере определяется ценностью информации, обрабатываемой ОО.

 

Но ITSEC были присущи и недостатки, которые могли негативно повлиять на эффективность ITSEC как инструмента оценки. Хотя в ITSEC не имелось никаких ограничений на определение для ОО набора функций безопасности, но были обозначены десять стандартных классов функций безопасности, для пяти из которых было установлено соответствие с классами TCSEC, а для оставшихся − с определенными типами систем. Такое решение делало ITSEC до некоторой степени зависимыми от TCSEC, что было не очень удачным решением в то время, когда уже начало складываться понимание того, что развитие идей, заложенных в ITSEC, неизбежно приведет к замене «радужной серии» более адекватными критериями оценки ИТ. В 1992 г. на очередной конференции в выступлениях было упомянуто о разработке (по некоторым данным, с ноября 1991 г.) NIST и АНБ новых федеральных критериев, в которых содержались как функциональные требования безопасности, так и требования доверия к безопасности [5]. В это же время NIST и АНБ приступили к разработке Federal Information Processing Standards Publications (FIPS), фактически запустив процесс развития нормативного обеспечения безопасности еще в одном независимом направлении. Таким образом, NIST и АНБ делали сразу несколько независимых ставок.

 

Общие критерии

В 1993 г. на очередной конференции широко обсуждался проект Federal Criteria for Information Technology Security (FC) [6]. Было отмечено, что FC безусловно представляют значительный шаг вперед по сравнению с TCSEC и FC неплохо гармонизированы с ITSEC. Но именно гармонизация с ITSEC и некоторая инерция мышления, унаследованная от TCSEC, предопределили недостатки FC. Как в ITSEC, в FC было установлено соответствие с классами TCSEC, требования доверия были разделены на две категории, в каждой из которых содержалось по несколько предопределенных классов, что чрезмерно усложнило их использование, не прибавив эффективности. По результатам рассмотрения более чем 20 тыс. комментариев, полученных в ответ на разосланные 10 тыс. экземпляров предварительной редакции FC, было принято решение придать проекту по разработке FC статус международного и силами США, Канады и европейского сообщества разработать общие критерии – Common Criteria (CC), которые должны быть гармонизированы со всеми существующими критериями. Старт работ по созданию CC был намечен на осень 1993 г., а весной 1994 г. уже планировалось получить первые результаты. Срок, надо отметить, чрезвычайно малый для работ такого масштаба и сложности.

В 1994 г. на очередной конференции сообщество было проинформировано о состоянии дел в области создания общих критериев CC [7]. Предварительная редакция CC была в апреле 1994 г. (Version 0.6, April 1994) рассмотрена интернациональной группой экспертов. Следующая предварительная редакция CC должна была быть доступна для публичного рассмотрения в конце 1994 г. (ею стала Version 0.9, October 1994). Предполагалось, что применение CC будет способствовать расширению рынка доверенных продуктов ИТ и взаимному признанию их результатов оценки национальными лабораториями. После выпуска официальной редакции CC ее планировали использовать в качестве основы для разработки соответствующего международного стандарта.

По мере развития CC в каждой последующей редакции потребители находили все больше того, что им было крайне полезно для оценки безопасности ИТ, и все меньше того, что накладывало бы какие-либо ограничения на применение CC для конкретного ОО. Редакцию 1 CC (Version 1.0, January 1996), после получения информации о ее применении, предполагалось передать в Международную организацию по стандартизации – International Organization for Standardization (ISO) в качестве основы для международного стандарта. В редакции 2 CC, начало подготовки которой был запланировано на первые месяцы 1997 г., предусматривалось продолжение работ по совершенствованию CC, прежде всего в направлении обеспечения взаимного признания результатов оценки безопасности ИТ лабораториями, находящимися в разных юрисдикциях. Получилось так, что в процессе их создания CC фактически были гармонизированы не столько со всеми имеющимися критериями оценки безопасности, как планировалось вначале, сколько с существующим уровнем развития ИТ и самыми передовыми (на момент создания CC) взглядами на проблематику и безопасность ИТ. Это сыграло не последнюю роль в том, что CC стали самодостаточным документом без всяких ссылок на те документы, с которыми CC вроде как должны были быть гармонизированы. Именно в CC проблематика безопасности ИТ перестала рассматриваться как самостоятельное направление и стала анализироваться только в неразрывной связи с ИТ. Такой взгляд на безопасность ИТ позволил CC естественно и бесконфликтно развиваться в том же темпе, в котором происходило развитие ИТ. Ведь не последней причиной, вызвавшей к жизни в конце 70-х гг. ХХ в. инициативу МО, было постоянно нарастающее отставание развития системы взглядов на проблемы безопасности от развития ИТ.

Именно в CC впервые был зафиксирован универсальный подход к оценке безопасности произвольно определяемого объекта оценки: подход, который является одновременно и риск-ориентированным и объектно-ориентированным. Такой подход необычайно гибок и позволяет рассматривать объект оценки в контексте произвольной политики безопасности организации, делать предположения безопасности, определять цели безопасности отдельно для ОО и среды его функционирования. Подход, в котором функциональные требования безопасности и требования доверия к безопасности можно адаптировать под конкретные цели безопасности по понятным и непротиворечивым правилам, а при необходимости группировать требования в пакеты. Подход, который предусматривает предопределенные пакеты требований доверия к безопасности (оценочный уровень доверия – Evaluation Assurance Level (EAL)), ранжированные по уровню затрат ресурсов на достижение необходимого уровня доверия к безопасности и, таким образом, впервые позволявшего рассматривать проблему безопасности ИТ и в контексте эффективности.

Но создание пригодной для практического использования редакции CC отнюдь не решило всех проблем США в области оценки безопасности ИТ, ибо по каким-то соображениям де-юре решение о замене «радужной серии» CC в полном объеме принято не было. Де-факто CC заменили «радужную серию» в части оценки безопасности. Это тем более странно, что к тому времени развитие «радужной серии» остановилось, и, по имеющейся у авторов информации, самый поздний документ «радужной серии» датирован 1995 г. В распоряжении авторов нет документов, на основании которых можно было бы делать выводы о причинах довольно длительного сосуществования «радужной серии» и CC, поэтому мы не станем ничего домысливать, а будем руководствоваться только фактами.

 

Новая эра оценки соответствия

Факты свидетельствуют о том, что лишь в 2002 г. был принят The Federal Information Security Management Act of 2002 (FISMA), который вместе с Paperwork Reduction Act of 1995 и Information Technology Management Reform Act of 1996 четко и недвусмысленно определял основанную на оценке рисков политику для обеспечения адекватной и рентабельной безопасности. Во исполнение FISMA, NIST в январе 2003 г. дал старт проекту FISMA Implementation Project, в ходе реализации которого были разработаны стандарты – Federal Information Processing Standards (FIPS) 199, FIPS 200 и специальные публикации – Special Publications (SP) 800-53, SP 800-59 и SP 800-60. Затем для дополнительной поддержки FISMA Implementation Project были разработаны специальные публикации SP 800-37, SP 800-39, SP 800-171, SP 800-53A и межведомственный отчет – (IR) 8011. В разработанных документах содержалось описание Risk Management Framework (RMF). Именно RMF де-юре заменил «радужную серию» в части описания требований к безопасности.

Подобно CC, RMF предусматривает универсальный подход к оценке безопасности произвольно определяемого объекта, поименованного как «информационная система» (ИС). Подход, который является одновременно и риск-ориентированным, и объектно-ориентированным. Диапазон понятия «информационная система» в рамках RMF представляется более узким, чем диапазон понятия «объект оценки» в рамках СС, но в любом случае в рамках RMF есть возможность оценивать объекты в существенно более широком диапазоне, чем это позволяла «радужная серия» в целом, не говоря уже об одном TCSEC.

RMF содержит описание довольно своеобразного подхода к оценке рисков. Вначале выполняется классификации ИС в зависимости от уровня предполагаемого ущерба, затем выбор из каталога мер безопасности (security and privacy controls), соответствующих установленному классу ИС, далее − реализация мер безопасности и лишь потом оценка рисков. Такой подход существенно отличается от классического, когда оценка производится дважды (первый раз – до выбора мер безопасности, второй – после выбора мер безопасности и их реализации). Однако это не означает, что подход, описанный в RMF, хуже или лучше, он просто другой. В известном смысле в RMF сохранена некоторая преемственность с TCSEC в части классификации объектов и выбора мер безопасности из конечного каталога. И если в TCSEC классификация объектов с высокой вероятностью определялась внутренними регламентами МО, то в случае RMF классификация определяется документом FIPS 199, входящим в RMF, в качестве критерия используется уровень предполагаемого ущерба. Аналогичная ситуация с каталогом мер безопасности: в TCSEC − это внутренний каталог, а в RMF − два каталога (краткий FIPS 200 и полный SP 800-53). А еще надо понимать, что люди, разрабатывавшие RMF, были хорошо информированы о том, что время доверенных КС наступило, они стали повсеместно доступны, поэтому имеется возможность оптимизировать подход к оценке рисков.

Кстати, в SP 800-53 Rev. 4 примерно 25% требований относится к категории уровня системы (The system), остальное – к категории уровня организации (The organization), что объяснимо: доверенные КС теперь уже есть и никуда не денутся, это техника и границы ее возможностей в принципе понятны, а вот требования к организации – это требования к менеджменту информационной безопасности (ИБ), а значит, к персоналу и к процессам, которые исполняет персонал, следовательно, это та область, где всегда есть «место подвигу». Но RMF не только заменил «радужную серию», но и фактически ознаменовал успешное завершение инициативы МО США по созданию доверенных КС. Правда, к 2003 г. система взглядов в области ИТ претерпела существенные изменения, и на смену попыткам построить конечную таксономию объектов ИТ пришло понимание того, что удобнее всего рассматривать ИТ и составляющие их компоненты с позиции «ВСЕ ЕСТЬ ОБЪЕКТ» и только по мере необходимости переходить к рассмотрению конкретных свойств для конкретного объекта. Можно сказать, что приход CC и RMF на смену «радужной серии» знаменовал в ИТ победу объектно-ориентированного подхода над функционально-модульным. Тезис о том, что отношения, заданные на множестве объектов, именуемом системой, вносят в характеристику системы гораздо больший вклад, чем конкретные свойства конкретного объекта, постулированный в книге М. Месаровича, Я. Такахары «Общая теория систем: математические основы», изданной в 1975 г., нашел подтверждение на практике. Чуть позже, в середине 1980-х гг. на это же было указано в появившихся стандартах ISO серии 9000, и далее системный подход аккуратно и неуклонно применялся во всех стандартах ISO (далее в переводных ГОСТ Р ИСО).

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

Необходимо отметить тот факт, что и CC, и RMF продолжают развиваться, и имеются четко отлаженные процедуры по их поддержанию в актуальном состоянии, адекватном текущему уровню развития ИТ и нуждам потребителей. FISMA от 2002 г. был дополнен документом The Federal Information Security Modernization Act of 2014, а последней редакцией CC по состоянию на 9 января 2018 г. является CC v3.1 Release 5. На основе каждой редакции CC ISO разрабатывает соответствующую редакцию стандарта ISO/IEC 15408 Information Technology. Security techniques. Evaluation criteria for IT security [9–11]. Несмотря то что CC и RMF на сегодняшний день являются «венцом творения» в области нормативных документов по безопасности ИТ, имеются обстоятельства их применения, которые, по мнению авторов, требуют осмысления для более точного понимания нынешнего состояния ИТ и выбора дальнейших путей развития инструментов оценки их безопасности.

RMF нацелен на информационные системы и организации (Information Systems and Organizations − как это следует из наименования многих документов RMF). RMF в части, касающейся ИС, предусматривает оценку их безопасности, а в части, касающейся организаций, − требования по менеджменту, направленные на обеспечение безопасности ИС. Однако авторам не известны свидетельства оценки безопасности по RMF каких-либо ИС и организаций. Вместе с тем, в документе SP 800-53 имеется приложение, в котором устанавливается соответствие между функциональными требованиями безопасности и требованиями доверия к безопасности ISO 15408, а также между мерами безопасности (security and privacy controls) SP 800-53 и мерами (controls) − ISO/IEC 27001 Information technology. Security techniques. Information security management systems. Requirements [12]. Вырисовывается интересная картина – свидетельств оценки безопасности по RMF вроде как нет, но в то же время SP 800-53 устанавливает соответствие с положениями документов (ISO 15408 и ISO 27001), по которым в мире проводится множество оценок безопасности. По мнению авторов, такая ситуация обусловлена тем, что в условиях, когда на рынке широко доступны продукты ИТ, прошедшие независимую оценку безопасности по ISO 15408, ИС, созданная из таких компонентов, имеет высокие шансы автоматически удовлетворять требования RMF, а требования RMF в части организации удовлетворяются за счет оценки соответствия менеджмента информационной безопасности (СМИБ) требованиям известного стандарта ISO 27001. По данным ISO, в мире выполнено более 23 тыс. сертификаций по требованиям ISO 27001. Возможно, что в организации и проводится некая «финишная» оценка безопасности ИС по RMF, выполняемая по упрощенной процедуре, но этот процесс непубличный, следовательно, никаких свидетельств тому в широком доступе нет. А потенциальных контрагентов организации если что и будет интересовать, то, скорее всего, не заключение об оценке безопасности по RMF, а международный признанный сертификат соответствия СМИБ требованиям ISO 27001.

 

Текущая диспозиция

Что мы имеем в сухом остатке на текущий момент? С одной стороны, самодостаточную номенклатуру зарубежных нормативных документов по безопасности ИТ, адекватность которых многократно подтверждена их практическим использованием испытательными лабораториями, соответствующими требованиям ISO/IEC 17025 General requirements for the competence of testing and calibration laboratories, в разных юрисдикциях. К указанным нормативным документам мы имеем такую же самодостаточную номенклатуру зарубежных продуктов ИТ, которые при необходимости и целесообразности проходят процедуру оценки функционала безопасности в испытательных лабораториях. Следует отметить, что в Белоруссии практика оценки по указанному стандарту обеспечивается совместным признанием результатов испытаний в национальной и международной признанной системах, предоставляя потенциальному заказчику возможность получения мирового признания. С другой стороны, мы имеем российские нормативные документы по безопасности ИТ, имеющие 25-летнюю историю (считая с документов Государственной технической комиссии при Президенте Российской Федерации (Гостехкомиссия) выпуска 1992 г.), и в этой истории не было такого периода, в течение которого эти документы были бы адекватны наилучшему современному им уровню развития ИТ. В 2017 г. Президент России В.В. Путин в своем выступлении на пленарном заседании Петербургского международного экономического форума (ПМЭФ-2017) так охарактеризовал ситуацию с нормативными документами по безопасности ИТ в России: «Первое – необходимо сформировать принципиально новую, гибкую нормативную базу для внедрения цифровых технологий во все сферы жизни. При этом все решения должны приниматься с учетом обеспечения информационной безопасности государства, бизнеса и граждан»[5].

Рассмотрим ситуацию с нормативными документами по безопасности ИТ в новейшей истории России подробнее. Тот факт, что в России никогда не было собственной самодостаточной номенклатуры ИТ, обусловил ее зависимость от зарубежного опыта, где самодостаточная номенклатура ИТ и нормативных документов по их безопасности как раз и была целенаправленным образом сформирована в процессе реализации инициативы МО и сопутствующих ей мероприятий, рассмотренных нами ранее. Но необходимым условием заимствования чужого опыта в условиях ограниченного доступа к предметной области является наличие квалифицированных аналитиков в профильной области. Однако собственных аналогов RAND Corporation или MITRE Corporation в России, к сожалению, не оказалось. Поэтому при заимствовании опыта сразу же возникли и в дальнейшем постоянно присутствовали проблемы и с переводом (в отрасли известны «уникальные переводы» ГОСТ Р ИСО/МЭК 20000-1 версии 2005 г.), и с пониманием сути вещей, усугубленные неоправданно ограниченным составом вовлеченных в процесс поиска сторон.

Еще в 1992 г. Гостехкомиссия выпустила два руководящих документа по защите от несанкционированного доступа (НСД) к информации для средств вычислительной техники (СВТ) и автоматизированных систем (АС), а в 1997 г. и для межсетевых экранов (МЭ). Все эти документы, безусловно, были созданы под впечатлением от «радужной серии». Но уже тогда для специалистов была понятна инновационная бесперспективность «радужной серии» в силу ее неадекватности текущему уровню развития ИТ. И даже по состоянию на 2017 г. «раритетные» документы Гостехкомиссии все еще продолжают действовать, не имея никаких шансов на достижение адекватности современному уровню развития ИТ. Достаточно упомянуть только один пример – заявленную Intel отмену в 2020 г. поддержки BIOS[6], при котором все существующие СЗИ НСД (Dallas Lock, SecretNet, «БлокХост» и пр.) автоматически становятся неприменимыми…

В 2007 г. Федеральная служба по техническому и экспортному контролю (ФСТЭК), пришедшая на смену Гостехкомиссии, выпустила пакет руководящих документов по защите ключевых систем информационной инфраструктуры (КСИИ), в которых излагался подход в определенной степени преемственный с «радужной серией». Практически все, что было «творчески» заимствовано из «радужной серии», пострадало при включении в документы ФСТЭК по КСИИ, а некоторые понятия были, к сожалению, значительно деформированы. Таким образом, процесс моделирования воздействия угроз на целевой объект из «радужной серии» трансформировался в статичную модель угроз в документах по КСИИ. В результате трансформации от «целевого объекта» остались лишь воспоминания, а вот предположения об угрозах и возможностях нарушителей претерпели настолько угрожающие метаморфозы и были настолько избыточно детализированы, что практически утратили связь с логикой. В частности, формулы для модели угроз из документов ФСТЭК по КСИИ неверны, многие допущения (рассматриваются только файлы) разрушают логику вывода расчетов и в результате любых произвольных комбинаций при вычислениях для реальных объектов КСИИ актуальность угроз почти всегда получается равной единице. Критика документов КСИИ была высказана еще много лет назад экспертным сообществом, в результате чего ни один из четырех документов не был утвержден в Минюсте. Между тем за рубежом, с уходом на покой «радужной серии», тема моделирования воздействия угроз была замещена такой традиционной и хорошо проработанной темой, как оценка рисков. Это положение справедливо и для отрасли атомной промышленности (документы МАГАТЭ), и для авиационного комплекса (документы ИАТА), в которых процедуры идентификации, оценки и обработки рисков описаны явно.

В 2008 г. Госдума приняла пакет документов по защите персональных данных, предусматривавших подходы к защите, в значительной степени аналогичные подходам, изложенным в документах по КСИИ, разве что формулы в модели угроз позволяли получать иногда степень защищенности, отличную от единицы. С 2013 г. ФСТЭК начала применять «новый подход» и выпустила три документа, известных как приказы № 17, № 21 и № 31, выдержанные в едином стиле. «Новый подход» на самом деле являл собой набор мер по защите информации, близко к тексту заимствованный из APPENDIX D SECURITY CONTROL BASELINES – SUMMARY документа NIST SP 800-53. К сожалению, SECURITY CONTROL пострадали при переводе, причем трижды (приказов тоже было три) и каждый раз по-разному.

В России существует мнение, что проблемы безопасности информации можно успешно решать в отрыве от ИТ, не затрагивая «базовые» «чистые» ИТ, а только применяя «наложенные меры безопасности», прошедшие установленные проверки в национальной системе. В 2002 г. ФСТЭК под собственной обложкой издала одну из ранних редакций ГОСТ Р 15408 (идентичен соответствующей редакции 15408 версии 2002 г., ныне отменен). Этот перевод в дальнейшем никак не поддерживался, даже тогда, когда соответствующая редакция ГОСТ Р ИСО/МЭК 15408 была заменена более новой. К сожалению, поддержка жизненного цикла нормативных документов во ФСТЭК отсутствует, хотя у наших коллег в ОАЦ и НИИ ТЗИ в Республике Беларусь все национальные стандарты (СТБ) всегда актуальны действующим версиям международных ISO и IEC. С 2012 г. ФСТЭК начала перевод системы сертификации на ГОСТ Р ИСО/МЭК 15408, в связи с чем была начата разработка профилей защиты (ПЗ). К сожалению, это движение не сопровождалось приведением испытательных лабораторий в соответствие с общепринятыми требованиями ISO 17025, что было бы крайне полезно с позиции повышения качества и прозрачности деятельности национальных лабораторий. И к профилям защиты тоже появилось много вопросов. Не выдерживалась структура профиля, хотя в ISO 15408 этому уделяется большое внимание из соображений совместимости. Не было возможности однозначно идентифицировать, на основе какой редакции стандарта разрабатывался ПЗ, ведь и по сей день имеется возможность разработки профиля на основе и ранней редакции ГОСТ Р ИСО/МЭК 15408 «под обложкой» ФСТЭК, и действующего ГОСТ Р ИСО/МЭК 15048, идентичного актуальному ISO 15408. Кроме того, количество ПЗ весьма значительно, а сами они избыточно объемные и неконкретные. Между тем успешный опыт организаций (National Information Assurance Partnership) свидетельствует о том, что на одну тему более чем достаточно одного ПЗ, адаптация же функциональных требований безопасности и требований доверия к безопасности под конкретные объекты оценки осуществляется на этапе разработки задания по безопасности.

Соответственно можно констатировать, что в России не прижилась главная идея, выстраданная международным сообществом экспертов и положенная в основу всех современных зарубежных нормативных документов по безопасности ИТ: безопасность есть неотъемлемая часть ИТ, в отрыве от ИТ безопасности не существует, а требования безопасности ИТ универсальны и едины вне зависимости от вида обрабатываемой информации. Адаптация же функционала безопасности проводится под конкретную систему обработки информации (СОИ) в соответствии с ее архитектурой. В зависимости от ценности обрабатываемой информации (но никак не от ее вида) предъявляются требования к корректности функционала безопасности СОИ (это требования доверия к безопасности из CC). Оценка достаточности и корректности функционала безопасности СОИ проверяется в ходе оценки безопасности ИТ. Для типовых случаев безопасность ИТ вытекает из правильного применения для построения СОИ продуктов ИТ, достаточность и корректность функционала безопасности которых проверены в независимых лабораториях, соответствующих международным требованиям ISO 17025. И количество таких продуктов на мировом рынке достаточно для удовлетворения потребности в безопасности. К сожалению, в России есть неразрешимые пока проблемы доверия к корректности функционала безопасности продуктов ИТ и для разрешения этих проблем необходимо подняться на иной уровень – обеспечить широкодоступную номенклатуру продуктов ИТ, обладающих достаточным и корректным функционалом безопасности, исследования, разработка и производство которых осуществлялась бы исключительно в российской юрисдикции. Все это позволит обеспечить цифровой суверенитет, о котором многократно публично говорили и Президент РФ В.В. Путин, и руководители профильных служб (ФСБ).

 

Итоги

О путях решения проблем с корректностью функционала безопасности продуктов ИТ в России мы планируем рассказать в статье, посвященной рассмотрению вопроса о возможности замещения в России импортных продуктов ИТ отечественными, которая выйдет в одном из следующих номеров журнала. А пока хотелось бы вернуться к ответу, данному в начале статьи. Мы надеемся, что после знакомства с представленными материалами вдумчивый читатель проверит все приведенные аргументы и убедится, что формирование адекватных требований к безопасности ИТ – не такая простая задача, как кажется на первый взгляд. Более 30 лет потребовалось сторонам, вовлеченным в 1978 г. в инициативу МО, чтобы сформировать набор адекватных нормативных документов по безопасности ИТ. Для сравнения: за 25 лет некоторые очень гибкие компании, наслышанные об инициативе МО, представили по несколько поколений различных продуктов ИТ с требуемым функционалом безопасности.

Целесообразно также ознакомиться с содержанием требований нового Федерального закона от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». За прошедшее время ему было посвящено несколько специализированных форумов, и авторы воздержатся от повторения экспертных мнений. Лучше обратим внимание на следующие важные факты.

1. Не установлена связь с имеющимися и реально работающими национальными стандартами ГОСТ Р ИСО/МЭК серии 27001 и 15408. В новом № 187-ФЗ ни разу не упоминаются ни системы независимых аудитов (которые, кстати, приняты в системе МАГАТЭ и ИАТА для объектов КИИ в РФ), ни системы менеджмента ИБ, ни применяемый в РФ порядок оценки соответствия.
2. Не установлена связь нового № 187-ФЗ с действующим № 184-ФЗ «О техническом регулировании», соответственно нет оснований полагать, как именно будет подтверждено объективное соответствие применяемых мер (средств) защиты на объектах КИИ заданным требованиям.
3. Статья 12 нового № 187-ФЗ «Оценка безопасности критической информационной инфраструктуры» не содержит ссылок ни на один из существующих независимых национальных центров подтверждения соответствия, более того, нет ссылок и на имеющийся механизм периодических, независимых, документированных аудитов ИБ, которые предусмотрены как в национальном ГОСТ РВ 0015-002-2012, так и в ГОСТ Р ИСО/МЭК 27001-2006.

 

Следует отметить, что в новом № 187-ФЗ нет никакого упоминания о риск-ориентированном подходе в ИБ, который уже можно отнести к классическим: стандарты в этой области приняты 13 лет назад (ISO/IEC 27001 впервые вышел в 2005 г., а его предтеча BS 7799 и того раньше…). Авторы просят обратить внимание, что статьи на эту тему публикуются с завидной частотой, и не только в области ИБ: серьезные исследования о проблемах безопасности АСУТП, формировании суверенных ИТ, доверии к иностранному ПО в ПЛК или системах MES/SCADA периодически появляются в открытых источниках и на специализированных конференциях.

 

А может, не надо ничего искать и ждать, выдумывать «уникальные» требования безопасности для АСУ ТП? Может быть, надо просто начать вдумчиво и методически аккуратно пользоваться имеющими международное признание адекватными и эффективными нормативными документами по безопасности ИТ − CC (или их репликой ISO 15408) и ISO 27001? Но каким образом? Ответ очень прост: путем синтеза «гибридных» методик оценки безопасности ИТ под конкретный объект СОИ. И если целевым объектом будет являться АСУ ТП, то объективная методика оценки безопасности будет синтезироваться с учетом особенностей конкретной АСУ ТП, в том числе с учетом вопросов функциональной безопасности. Но эта тема заслуживает отдельной статьи.

 

Литература

1. Proceedings of the seminar on the DoD computer security initiative program National bureau of standards Gaithersburg, Maryland, July 17−18, 1979.
2. Proceedings of the fifth seminar on the DoD computer security initiative program National bureau of standards Gaithersburg, Maryland, May 24−26, 1982.
3. Proceedings of the sixth seminar on the DoD computer security initiative program National bureau of standards Gaithersburg, Maryland, November 15−17, 1983.
4. 13th National Computer Security Conference, Omni Shoreham Hotel, Washington D.C., October 1−4, 1990.
5. 15th National Computer Security Conference, Baltimore Convention Center Baltimore, MD, October 13−16, 1992.
6. 16th National Computer Security Conference, Baltimore Convention Center, Baltimore, MD, September 20−23, 1993.
7. 17th National Computer Security Conference, Baltimore Convention Center, Baltimore, MD, October 11−14, 1994.
8. 19th National Information Systems Security Conference Proceedings, Baltimore, MD, October 22−25, 1996.
9. ISO/IEC 15408-1:2009 Information technology. Security techniques. Evaluation criteria for IT security. Part 1: Introduction and general model.
10. ISO/IEC 15408-2:2008 Information technology. Security techniques. Evaluation criteria for IT security. Part 2: Security functional components.
11. ISO/IEC 15408-3:2008 Information technology. Security techniques. Evaluation criteria for IT security. Part 3: Security assurance components.
12. ISO/IEC 27001:2013. Information technology. Security techniques. Information security management systems. Requirements, International Organization for Standardization.

[1]                                     Министерство обороны США.

[2]                                     Так в США именуется информация, содержащая сведения, составляющие государственную тайну.

[3]                                     Документ также известен как «оранжевая книга».

[4]                   Здесь понятия «неформальный», «полуформальный» и «формальный» соответствуют их определению в документе Common Criteria for Information Technology Security Evaluation.

[5]                                            http://www.econominews.ru/finansy/334-vystuplenie-vladimira-putina-na-plenarnom.html

[6]                                            https://www.securitylab.ru/news/489782.php

Следите за нашими новостями в Телеграм-канале Connect

Следите за нашими новостями в
Телеграм-канале Connect