Общее описание процедуры аттестации автоматизированных систем по требованиям информационной безопасности
Автор: Пользователь скрыл имя, 23 Декабря 2012 в 18:19, курсовая работа
Описание работы
В современных условиях наиболее перспективным способом проверки достигнутого качества функционирования и уровня защищенности автоматизированных систем (АС) является процедура аттестации. В то время как для многих коммерческих АС аттестация носит добровольный характер, существует достаточно многочисленная категория АС, для которых аттестация, согласно действующему законодательству, является обязательным условием для начала или продолжения их эксплуатации.
Работа содержит 1 файл
Общее описание процедуры
аттестации автоматизированных
систем по требованиям
информационной безопасности
Введение
В современных условиях наиболее перспек
тивным способом проверки достигнутого качества
функционирования и уровня защищенности авто
матизированных систем (АС) является процедура
аттестации. В то время как для многих коммерчес
ких АС аттестация носит добровольный характер,
существует достаточно многочисленная категория
АС, для которых аттестация, согласно действующе
му законодательству, является обязательным усло
вием для начала или продолжения их эксплуатации.
В их число входят АС, предназначенные для обра
ботки информации, составляющей государствен
ную тайну, для управления экологически опасными
объектами и для ведения секретных переговоров.
В России аттестация по существу только на
чинает внедряться в практику создания и примене
ния АС. В связи с этим существует целый комплекс
нерешенных проблем, в числе которых проблемы
стандартизации и совершенствования нормативной
документации, состоящие в разработке, выборе и
адаптации документов, применяемых при аттеста
ции и описывающих процедуру, критерии и методи
ку ее проведения. Целесообразным является ис
пользование для решения этих проблем опыта, на
копленного мировым сообществом.
В США набор руководящих документов в об
ласти аттестации был сформирован еще в начале
80х годов. Изучение и адаптация этих документов к
российским условиям может существенно ускорить
процесс создания отечественной нормативной ба
зы. Для федеральных органов США основополагаю
щим документом в области аттестации является Ру
ководство по Проведению Аттестации и Аккредита
ции безопасности АС (FIPS PUB 102).
Данная работа является попыткой использо
вания отечественного опыта и американской норма
тивной базы для создания общего руководства по
проведению аттестации АС по требованиям безо
пасности информации.
Используемая терминология
Система аттестации АС является составной
частью Единой системы сертификации средств за
щиты информации (СЗИ) и аттестации объектов
информатизации по требованиям безопасности ин
формации, организация функционирования кото
рой осуществляется Гостехкомиссией при Прези
денте РФ. В соответствии с принятой в нашей стра
не концепцией защиты информации от несанкцио
нированного доступа (НСД), существует два относи
тельно самостоятельных направления решения этой
проблемы: направление, связанное со средствами
вычислительной техники (СВТ), и направление, свя
занное с АС. Отличие между этими направлениями
заключается в том, что при рассмотрении вопросов
защиты СВТ огрганичиваются только программно
техническими аспектами функционирования систе
мы, в то время как защита АС предполагает рассмо
трение организационных мер защиты, вопросов
физического доступа, защиты информации от утеч
ки по техническим каналам и т. п. СВТ представляют
собой программнотехнические средства, разраба
тываемые и поставляемые на рынок как элементы,
из которых строятся АС. Помимо набора СВТ, АС
включает в себя обслуживающий персонал и систе
му организационных мероприятий, обеспечиваю
щих ее функционирование, а также помещения,
пользовательскую информацию, бумажную доку
ментацию и т. д. Существование двух условно раз
личающихся направлений в защите информации
является причиной отличия используемой в нашей
стране терминологии от принятой в других странах.
Понятие «сертификация по требованиям безопас
ности» в России применяется по отношению к СВТ,
в то время как тот же самый процесс по отношению
к АС называется аттестацией. В США в обоих случа
ях используется понятие «сертификация».
Cогласно американским руководящим доку
ментам, сертификация по требованиям безопаснос
ти – это проводимый независимыми экспертами
комплекс организационнотехнических мероприя
Александр Астахов
тий по проверке соответствия реализованных в АС
или СВТ механизмов безопасности определенному
набору требований. Требования безопасности ис
пользуются в качестве критерия для оценки уровня
защищенности АС или СВТ. Они могут быть сфор
мулированы в руководящих документах органов го
сударственного управления, внутриведомственных
и межведомственных приказах, национальных и
международных стандартах, стандартизированных
профилях защиты или заданиях по безопасности, а
также в виде требований конкретной организации
или пользователей АС.
Примечание: Для определенности, в осталь
ной части настоящей статьи по отношению к АС
будет использоваться принятый в нашей стране
термин – аттестация.
В случае положительного результата аттеста
ционных испытаний создается специальный доку
мент – «Аттестат соответствия», в котором под
тверждается, что объект испытаний соответствует
требованиям стандартов или иных нормативнотех
нических документов по информационной безопас
ности. Таким образом, основным продуктом аттес
тации является аттестат соответствия. Но не менее
важным является то, что к проведению обследова
ния и аттестационных испытаний активно привле
кается обслуживающий персонал АС, ее разработ
чики и пользователи, в результате чего повышается
их осведомленность в вопросах обеспечения безо
пасности и общий уровень защищенности АС.
Аттестация АС по требованиям безопасности
информации является лишь одним из аспектов об
щей процедуры аттестации, выполняемой с целью
получения гарантий того, что АС удовлетворяет
предъявляемым к ней требованиям по функцио
нальности, производительности, безопасности, ка
честву и надежности функционирования. Поэтому
ее лучше всего осуществлять как часть общей про
цедуры аттестации, охватывающей все требования
к эффективности функционирования АС и зачас
тую использующей те же методы проведения обсле
дования и испытаний.
В американской нормативной документации
термин «сертификация» применяется по отноше
нию к программному обеспечению, аппаратным
компонентам, приложениям, системам, термина
лам, сетям и другим объектам. Природа сертифици
руемого объекта оказывает минимальное влияние
на общий процесс проведения аттестации, хотя она
оказывает существенное влияние на детали выпол
нения отдельных работ.
В США термином «аккредитация безопаснос
ти АС» обозначается основывающаяся на результа
тах аттестации санкция руководства предприятия,
позволяющая использовать АС для обработки жиз
ненноважной и/или конфиденциальной информа
ции в данной среде функционирования.
Таким образом, аккредитация является офи
циальным разрешением руководства использовать
данную АС в данной среде функционирования. Хо
тя в этом определении фигурируют только «жиз
ненноважные и/или конфиденциальные данные»,
предполагается его более широкая трактовка, охва
тывающая также критичные АС, которые могут ине
содержать жизненноважных и/или конфиденци
альных данных. Такие АС считаются критичными
скорее изза того вреда, который может быть нане
сен организации в случае отказа в обслуживании
этой АС, чем от несанкционированного раскрытия
или использования данных.
Критичные АС – это АС, для которых необ
ходима определенная степень защищенности, пото
му что они обрабатывают критичные данные или су
ществует риск причинения вреда в результате их
неправильного функционирования или злоумыш
ленного манипулирования ими.
Все АС имеют определенную степень критич
ности. Важным вопросом является наличие согла
шения о том, для каких АС требуется проводить ат
тестацию. Желательно иметь упорядоченный по
приоритетам список таких АС.
Описание процедуры аттестации
Процедуру аттестации АС можно условно
разделить на несколько последовательных этапов:
планирование, сбор информации, базовый анализ,
детальный анализ, подготовка отчетных документов
и аккредитация. Далее рассматривается содержа
ние каждого из этих этапов.
Планирование
План подготовки и проведения аттестации
должен определять проблемные области, потребно
сти в специальных знаниях, потребности в инстру
ментарии для поддержки процедуры оценивания и
другие вопросы, ответы на которые невозможно
дать без проведения соответствующего анализа, ха
рактерного для этапа базового оценивания и специ
фичного для каждой конкретной ситуации. Можно
выделить четыре стадии планирования:
•Инициирование.
•Анализ.
•Планирование ресурсов.
•Документирование плана проведения аттеста
ции.
Инициирование
На этапе инициирования осуществляется опре
деление общей схемы проведения аттестации и ее со
гласование с заказчиком работ. Схема определяет об
щий порядок выполнения работ и необходимые затра
ты ресурсов. Рассматриваются следующие вопросы:
Александр Астахов
1.Назначение, выполняемые функции и структу
ра объекта информатизации; критичность АС и
обрабатываемой в ней информации; границы
проведения обследования; узкие места и про
блемные области; состав и структура комплекса
средств защиты; привлечение для проведения
работ специалистов различных технических
профилей.
2.Оценка временных затрат и затрат ресурсов на
проведение работ; наличие результатов ранее
проведенного анализа рисков и аудита безопас
ности, которые можно было бы использовать
для определения трудоемкости и объема работ
по аттестации.
3.Состав экспертной группы; распределение обя
занностей между специалистами.
4.Факторы, оказывающие влияние на качество и
глубину аттестационных испытаний.
5.Наличие специфических для данного объекта
требований, которые должны использоваться в
качестве критерия для проведения аттестации,
помимо имеющейся нормативной документации.
6.Наличие и полнота документации, документи
рованность используемых механизмов безо
пасности.
7.Наличие и документированность политики бе
зопасности организации.
Принятая схема проведения аттестации
оформляется в виде Технического задания и Плана
графика работ.
Анализ
Анализ составляет основную часть процесса
планирования. В процессе анализа рассматривают
ся следующие вопросы:
1.Требования безопасности
2.Исходные данные
3.Границы проведения аттестации и распределе
ние работ
4.Области повышенного внимания
5.Требуемый уровень детализации
Анализ требований безопасности
Целью аттестации является проверка соответ
ствия исследуемой АС предъявляемым к ней требо
ваниям безопасности. Поэтому анализ начинается с
рассмотрения требований безопасности. Основным
критерием для аттестации служат требования, сфор
мулированные в виде руководящих документов Гос
техкомиссии РФ, законов РФ, внутриведомствен
ных, межведомственных, национальных и междуна
родных стандартов. Для каждой АС рассматривается
также набор внутренних требований, которые фор
мулируются по результатам анализа рисков и учиты
вают специфику и особенности среды функциони
рования исследуемой АС. Некоторые внутренние
требования могут быть очень специфичными для
данной АС и касаться критичности данных, ограни
чений на раскрытие некоторых видов информации и
других вопросов безопасности.
Общее описание процедуры аттестации автоматизированных систем
Начало
Планирование
Анализ
Планирование ресурсов
Что должно быть сделано?
1. Трудозатраты
2. Технические средства
3. Поддержка
Документирование плана
проведения аттестации
Инициирование
Определение общей схемы
проведения аттестации
1. Критерии оценки защищенности
2. Исходные данные
3. Границы проведения аттестации и
распределение работ
4. Области повышенного внимания
5. Уровень детализации
Рис. 1. Планирование процедуры аттестации.
Анализ состава исходных данных
Для разработки программы и методики аттес
тационных испытаний помимо стандартного переч
ня исходных данных, содержащегося в РД Гостехко
миссии «Положение по аттестации объектов ин
форматизации по требованиям безопасности ин
формации», необходимо предоставить также допол
нительные данные, состав которых уточняется в
каждой конкретной ситуации. Например, сообще
ния об известных слабостях АС, попытках НСД к
информации или отчеты о возникших проблемах,
полученные в ходе предшествующего периода ее
эксплуатации, приводят к необходимости сбора до
полнительных сведений из более узких областей.
Руководство организации, владеющей либо
эксплуатирующей АС, может иметь собственное
мнение по поводу информации, которая может быть
предоставлена в качестве исходных данных для ат
тестации. При планировании эти мнения необходи
мо учитывать. Например, для обеспечения сохран
ности коммерческой тайны между заказчиком и ис
полнителем работ может быть заключено соглаше
ние о конфиденциальности.
Определение границ проведения аттестации и рас
пределение работ
При определении границ проведения аттеста
ции необходимо в равной степени учитывать орга
низационный, физический и программнотехничес
кий уровни обеспечения безопасности. В против
ном случае результаты аттестации не будут отра
жать реальный уровень защищенности АС. Напри
мер, надежные технические методы защиты
окажутся бесполезными, если неправильно опреде
лен состав административных мероприятий или ме
ры обеспечения физической безопасности являют
ся неадекватными.
После определения границ проведения аттес
тации необходимо задокументировать предположе
ния относительно среды функционирования. На
пример, если операционная система не попадает в
границы объекта исследования, то нужно задоку
ментировать предположение о том, что ОС обеспе
чивает достаточный базовый уровень защищеннос
ти в таких областях, как изоляция процессов, аутен
тификация, авторизация, мониторинг, контроль це
лостности, регистрация и учет событий и т. п. Пред
положения относительно среды и условий
функционирования АС указываются в «Аттестате
соответствия» и являются необходимым условием
для разрешения обработки в АС критичной либо
конфиденциальной информации.
Когда границы проведения аттестации опре
делены, осуществляется распределение ответствен
ности между специалистами экспертной группы. В
большинстве случаев в подготовке и проведении ат
тестационных испытаний требуется участие специ
алистов различных технических профилей.
При определении состава экспертной группы
и распределении работ учитывается ряд характери
стик АС. Основные характеристики, на которые об
ращается внимание, включают количество и слож
ность программнотехнических компонентов АС и
их документированность.
Количество и сложность программнотехни
ческих компонентов АС определяют объем трудоза
трат, необходимый для проведения аттестации. Кро
ме того, следует учитывать такие характеристики
АС, как физическая, логическая или функциональ
ная распределенность ее компонентов.
Документированность АС является важным
фактором при планировании процедуры аттестации.
Необходимо учитывать наличие описания подсисте
мы информационной безопасности АС, включая опи
сание механизмов безопасности, комплекса средств
защиты и системы организационных мероприятий;
делается ли в документации разделение между меха
низмами безопасности и другими механизмами; доку
ментированы ли функциональные требования, име
ются ли спецификации системы, тестовая документа
ция, справочные руководства и т. п. Учитывается так
же полнота представленной документации, ее соот
ветствие текущему состоянию дел, требованиям
нормативной и методической документации.
Области повышенного внимания
При проведении аттестационных испытаний
основное внимание должно уделяться компонентам
и подсистемам, осуществляющим передачу, обработ
ку и хранение критичной информации. Критичность
информации определяется величиной возможного
ущерба, который может быть нанесен организации в
случае нарушения безопасности этой информации.
Помимо критичности информации на опре
деление областей повышенного внимания могут
также влиять и другие факторы. Например, меньше
внимания может уделяться тем компонентам АС,
все уязвимости которых уже хорошо изучены. Од
нако, существование этих уязвимостей должно най
ти отражение в документах.
Для определения областей повышенного вни
мания и концентрации усилий при аттестации могут
использоваться различные методы экспертных оце
нок. Например, широко распространенный метод
Дельфи. В качестве исходных данных для принятия
решения могут служить результаты проведения ау
дита безопасности, либо комплексного аудита АС,
результаты анализа рисков и данные об имевших
место нарушениях безопасности. Уязвимые места,
требующие особого внимания, могут быть выявле
ны по результатам опросов пользователей и обслу
живающего персонала.
Требуемый уровень детализации
В большинстве случаев для получения адек
ватных результатов достаточно провести базовый
анализ механизмов безопасности АС, позволяющий
Александр Астахов
определить общий уровень ее защищенности и сте
пень соответствия требованиям безопасности. Базо
вый анализ ограничивается уровнем функциональ
ных спецификаций и заключается в проверке нали
чия в составе системы компонентов, реализующих
необходимый набор требований безопасности.
В некоторых ситуациях, по причине высокой
критичности обрабатываемой информации или когда
механизмы безопасности расположены на нижних
уровнях абстракции и невидимы на верхних уровнях,
оправдано проведение детального анализа. При де
тальном анализе не ограничиваются констатацией
факта наличия необходимых функций безопасности,
но оценивают также эффективность их реализации.
Существует большое количество критериев
для определения уровня детализации, используемо
го при аттестации. В большинстве случаев основны
ми критериями являются: критичность АС, состав
исходных данных (например, доступность исходных
текстов программ) и размещение механизмов безо
пасности (используются встроенные или наложен
ные средства защиты). Другими критериями могут
служить: степень детализации, необходимая заказ
чику, размер и сложность АС, опыт экспертов. Ре
шения, принятые на основании перечисленных вы
ше критериев, могут относиться как ко всей АС, так
и к ее отдельным компонентам и подсистемам.
Планирование ресурсов
На основе проведенного анализа осуществля
ется выделение ресурсов (временных, людских, тех
нических средств и т. п.), необходимых для выполне
ния намеченных задач. Оценка времени включает
не только время, необходимое для решения постав
ленных задач, но также, и время связанное с реше
нием организационных вопросов при выделении со
ответствующих ресурсов. Выделение ресурсов про
изводится с учетом возможных незапланированных
ситуаций, способных оказать влияние на доступ
ность людских и других ресурсов.
Документирование плана
проведения аттестации
На основе проведенного анализа осуществля
ется подготовка и согласование плана проведения
аттестации, который в общем случае включает в се
бя следующие разделы:
1.Резюме. Включает все необходимые сведения о
порядке проведения работ.
2.Введение. Описывает структуру АС и границы
проведения обследования, уровень критичности
обрабатываемой информации и других ресур
сов, группы задач, решаемых системой, и огра
ничения, накладываемые политикой безопасно
сти, общий график работ, а также критерии для
оценки уровня защищенности АС, включая тре
бования нормативных документов и требова
ния, специфичные для данной АС.
3.Распределение ответственности. Определяется
организационная структура и обязанности экс
пертной группы и других участников процедуры
аттестации. Определяются обязанности обслу
живающего персонала по поддержке процеду
ры аттестации.
4.Требования безопасности. Определяется набор
требований безопасности, используемых в каче
стве критерия при аттестации. Помимо сущест
вующей нормативной базы обычно имеются до
полнительные требования, предъявляемые
пользователями и политикой безопасности орга
низации и специфичные для исследуемой АС.
Универсальным методом для определения тре
бований безопасности, адекватных существую
щим угрозам, является анализ рисков.
5.Подход к оцениванию. В этом разделе перечисля
ются задачи, выполняемые при проведении базо
вого анализа и, в случае необходимости, детально
го анализа. Осуществляется распределение работ
между участниками процедуры аттестации. Со
став задач сильно зависит от того, находится ли
АС на стадии разработки или на стадии эксплуа
тации. Затрагиваются следующие вопросы: обла
сти повышенного внимания, уровни детализации,
конкретные задачи и используемые методы про
ведения испытаний, источники информации.
6.Планграфик работ. Определяет сроки подго
товки промежуточных отчетных документов и
исходных данных, сроки проведения совещаний
и сроки окончания этапов выполнения работ.
Сроки подготовки промежуточных отчетов оп
ределяются на основании оценки времени, сде
ланной на этапе планирования ресурсов.
7.Поддержка. Перечисляются требования к видам
административной и технической поддержки
процедуры аттестации со стороны обслуживаю
щего персонала и руководства организации.
8.Отчетные документы. Основными отчетными
документами являются отчет по результатам
предварительного обследования объекта инфор
матизации, программа и методика проведения
аттестационных испытаний, протокол испыта
ний и заключение по результатам испытаний.
9.Приложения. В приложениях приводится струк
тура отчета по результатам аттестационных ис
пытаний, а также информация по методам и
средствам, которые использовались при прове
дении испытаний и анализа или даются ссылки
на источники такой информации.
Различия между процедурами аттестации,
выполняемыми на стадии разработки АС и на ста
дии ее эксплуатации, проявляются при рассмотре
нии деталей выполнения отдельных задач. Напри
мер, при тестировании механизмов безопасности,
аттестация, проводящаяся на стадии разработки,
Общее описание процедуры аттестации автоматизированных систем
располагает только данными тестирования, в то вре
мя как на стадии эксплуатации доступны также дан
ные аудита и мониторинга безопасности.
Сбор информации
Большая часть работы, выполняемой при ат
тестации (включая фазу планирования), заключает
ся в сборе информации. Рассмотрим три основных
метода сбора информации:
1.Получение информации от обслуживающего
персонала и разработчиков АС.
2.Изучение документации.
3.Проведение опросов.
При проведении аттестации наибольшее коли
чество времени тратится на изучение характеристик
АС. При изучении АС рассматриваются два основных
вопроса: (1) назначение и принципы функционирова
ния АС, (2) уровень защищенности АС (угрозы безо
пасности, ресурсы, механизмы защиты, уязвимости).
Оба эти вопроса могут быть разрешены при изучении
документации и в ходе опросов пользователей и раз
работчиков АС. Однако, эти способы сбора информа
ции требуют больших временных затрат.
В идеале лучшим источником информации об
объекте информатизации является проектная, рабо
чая и эксплуатационная документация. К сожале
нию, качество документации часто бывает низким, а
иногда она просто отсутствует. С другой стороны,
там, где она существует, ее объем может исчислять
ся сотнями и тысячами страниц печатного текста.
Документация также может содержать устаревшие
сведения. Механизмы безопасности в документа
ции часто не отделяются от других механизмов или
вообще не описываются. Поэтому существующая
документация зачастую трудна для изучения и не
содержит достаточного количества исходных дан
ных для аттестации.
Метод проведения опросов также не лишен
недостатков. Одним из основных недостатков этого
метода является то, что для получения необходимой
информации требуются значительные затраты вре
мени. Типичный опрос требует, по крайней мере,
один человекодень работы, включая время его под
готовки и документирования, и отнимает время и у
проводящих опрос, и у опрашиваемых.
Наиболее эффективным методом сбора ин
формации об АС является метод, при котором руко
водство организации, разрабатывающей либо экс
плуатирующей АС, ставит перед ее разработчиками
или обслуживающим персоналом задачу подгото
вить эту информацию и представить ее в эксперт
ную группу.
Для проведения аттестационных испытаний
должны быть подготовлены следующие документы:
1.Документы, содержащие требования безопас
ности.
2.Отчет по результатам анализа рисков.
3.Диаграммы информационных потоков прило
жений.
Документы, содержащие требования
безопасности
Требования безопасности являются критерием
для проведения аттестации. Если требования безопас
ности не были должным образом сформулированы, то
это делается в ходе аттестации. Формулировка требо
ваний является результатом совместной работы спе
циалистов, осуществляющих поддержку АС, и экспер
тов, проводящих ее аттестацию. Участие экспертов,
проводящих аттестацию, необходимо по той причине,
что у специалистов по поддержке АС недостаточно
знаний в области информационной безопасности,
особенно в отношении нормативной и правовой базы.
Участие специалистов по поддержке АС необходимо
по причине недостаточного понимания экспертами,
проводящими аттестацию, особенностей функциони
рования АС, а также требований пользователей.
Типичный набор руководящих документов,
используемых при аттестации АС в нашей стране,
включает в себя, но не исчерпывается, следующими
документами:
•Закон РФ от 20 февраля 1995 г. № 24Ф3 «Об ин
формации, информатизации и защите инфор
мации»;
•Закон РФ от 4 июля 1996 г. № 85Ф3 «Об участии
в международном информационном обмене»;
•Указ Президента РФ от 6 марта 1997 г. № 188 «Об
утверждении перечня сведений конфиденци
ального характера»;
Александр Астахов
Сбор информации
Опросы разработчиков
и пользователей АС
Изучение документации
Рис. 2. Сбор информации для аттестации.
•«Автоматизированные системы. Защита от не
санкционированного доступа к информации.
Классификация АС и требования к защите ин
формации», Гостехкомиссия России, 1997;
•«Средства вычислительной техники. Защита от
НСД к информации. Показатели защищенности
от НСД к информации», Гостехкомиссия Рос
сии, 1992.
Из перечисленных нормативных документов
последние два имеют особое значение для аттестации.
Руководящий документ (РД) Гостехкомис
сии РФ «СВТ. Защита от НСД к информации. Пока
затели защищенности от НСД к информации» ус
танавливает классификацию СВТ по уровню защи
щенности от несанкционированного доступа к ин
формации на базе перечня показателей защищен
ности и совокупности описывающих их
требований. Устанавливается семь классов защи
щенности СВТ от НСД к информации. Самый низ
кий класс седьмой, самый высокий первый. Классы
подразделяются на четыре группы, отличающиеся
уровнем защищенности:
•первая группа содержит только один седьмой
класс;
•вторая группа характеризуется дискреционной
защитой и содержит шестой и пятый классы;
•третья группа характеризуется мандатной защи
той и содержит четвертый, третий и второй
классы;
•четвертая группа характеризуется верифициро
ванной защитой и содержит только первый класс.
РД Гостехкомиссии РФ «АС. Защита от НСД к
информации. Классификация АС и требования по
защите информации» устанавливает классифика
цию АС, подлежащих защите от несанкционирован
ного доступа к информации, и требования по защи
те информации в АС различных классов. Определя
ющими признаками, по которым производится
группировка АС в различные классы, являются:
•наличие в АС информации различного уровня
конфиденциальности;
•уровень полномочий субъектов доступа АС на
доступ к конфиденциальной информации;
•режим обработки данных в АС – коллективный
или индивидуальный.
Устанавливается девять классов защищенно
сти АС от НСД к информации. Каждый класс харак
теризуется определенной минимальной совокупно
стью требований по защите. Классы подразделяют
ся на три группы, отличающиеся особенностями об
работки информации в АС. В пределах каждой груп
пы соблюдается иерархия требований по защите в
зависимости от ценности и конфиденциальности
информации и, следовательно, иерархия классов за
щищенности АС.
Кроме этого, в зависимости от характера АС,
могут использоваться другие руководящие докумен
ты Гостехкомиссии РФ, содержащие требования,
предъявляемые к конкретным классам СВТ, входя
щим в состав АС.
Отчет по результатам анализа рисков
Анализ рисков на объекте информатизации
проводится с целью обоснования требований безо
пасности, предъявляемых к АС, уточнения состава
этих требований и выработки системы контрмер,
необходимых для успешного противодействия су
ществующим в данной среде угрозам безопасности.
Отчет по результатам анализа рисков содержит опи
сание ресурсов АС, оценку их критичности, описа
ние существующих угроз и уязвимостей, оценку
ущерба, связанного с осуществлением угроз, и
оценку рисков. Оценка рисков определяется веро
ятностью осуществления угрозы, величиной уязви
мости и величиной возможного ущерба, причиняе
мого организации в случае успешного осуществле
ния угрозы. Проведение анализа рисков требует де
ятельного участия специалистов, отвечающих за
эксплуатацию АС.
Диаграммы информационных пото
ков приложений
Диаграммы информационных потоков при
ложений описывают входные, выходные и внутрен
ние информационные потоки приложений, выпол
няющихся в рамках АС. Диаграммы информацион
ных потоков необходимы для понимания принци
пов функционирования АС. Этот документ готовит
ся при участии специалистов, отвечающих за
поддержку АС.
Описание механизмов
безопасности АС
К механизмам безопасности относится любая
реализация защитных мер, включая организацион
ный, физический и программнотехнический уров
ни, а также любые действия и процедуры, уменьша
ющие вероятность нарушения безопасности АС.
Документы, содержащие описание механиз
мов безопасности АС, полученные от разработчи
ков или обслуживающего персонала АС, должны
подкрепляться изучением документации и проведе
нием опросов.
Базовый анализ
Аттестация может проводиться на двух уров
нях детализации: базовый анализ и детальный ана
лиз. Основное отличие между базовым и детальным
анализом заключается в том, что базовый анализ кон
центрируется главным образом на общих функцио
нальных возможностях обеспечения безопасности
АС, а не на особенностях отдельных защитных меха
Общее описание процедуры аттестации автоматизированных систем
низмов. Например, при базовом анализе определяет
ся, является ли достаточным контроль доступа на
уровне файлов или на уровне отдельных записей; до
статочно ли осуществлять аутентификацию на уров
не хостов или на уровне пользователей. При базовом
анализе также проверяется существование механиз
мов безопасности. При детальном анализе проверя
ется правильность функционирования механизмов
безопасности, удовлетворяют ли они критерию про
изводительности, являются ли они достаточно надеж
ными и их устойчивость к попыткам взлома.
В ходе базового анализа решаются следую
щие основные задачи:
1.Оценка адекватности требований безопасности.
2.Оценка адекватности механизмов безопасности.
3.Проверка существования механизмов безопас
ности.
4.Обзор методологии реализации механизмов бе
зопасности.
Оценка адекватности требований
безопасности
Основной целью аттестации является провер
ка соответствия механизмов безопасности АС предъ
являемым к ним требованиям. Поэтому требования
безопасности должны быть четко определены и
должны быть адекватны существующим рискам. Для
большинства АС не существует четко определенного
набора адекватных требований безопасности.
На этапе базового анализа существующие
требования безопасности должны быть критически
исследованы с целью определения их пригодности
для целей аттестации и соответствия ожиданиям
пользователей, политике безопасности организа
ции, законодательной и нормативной базе. Основ
ная часть требований может содержаться в техниче
ском задании на создание АС.
Если требования безопасности ранее не были
определены и документированы, то их необходимо
сформулировать и документировать в процессе ана
лиза рисков.
Как при определении, так и при оценке адек
ватности требований безопасности рассматривают
ся два класса требований: общие требования и тре
бования, специфичные для исследуемой АС. Общие
требования формулируются на основе федераль
ных законов, руководящих документов государст
венных органов, стандартов и политики безопаснос
ти организации. Специфичные требования форму
лируются в процессе анализа рисков.
Мероприятия по анализу и управлению рисками
Анализ рисков – это то, с чего должно начи
наться построение любой системы информацион
ной безопасности. Он включает в себя мероприятия
по обследованию безопасности АС, целью которых
является определение того, какие ресурсы и от ка
ких угроз надо защищать, а также в какой степени
те или иные ресурсы нуждаются в защите. Опреде
ление набора адекватных контрмер осуществляется
в ходе управления рисками. Ниже раскрываются
сущность и содержание мероприятий по анализу и
управлению рисками.
Риск определяется вероятностью причинения
ущерба и величиной ущерба, наносимого ресурсам
АС в случае осуществления угрозы безопасности.
Анализ рисков состоит в том, чтобы выявить
существующие риски и оценить их величину, т. е.
дать им количественную оценку. Его можно разде
лить на несколько последовательных этапов:
•Идентификация ключевых ресурсов АС.
•Определение важности тех или иных ресурсов.
•Идентификация существующих угроз безопас
ности и уязвимостей, делающих возможным
осуществление угроз.
Александр Астахов
Базовый анализ
Оценка адекватности
требований безопасности
Оценка адекватности
механизмов безопасности
Проверка существования
механизмов безопасности
Обзор методологии
проектирования
Рис. 3. Этапы базового анализа АС
•Вычисление рисков, связанных с осуществлени
ем угроз безопасности.
Ресурсы АС можно разделить на три категории:
•Информационные ресурсы.
•Программное обеспечение.
•Технические средства.
В каждой категории ресурсы можно разде
лить на классы и подклассы. Необходимо идентифи
цировать только те ресурсы, которые определяют
функциональность АС и существенны с точки зре
ния обеспечения безопасности.
Важность (или стоимость) ресурса определя
ется величиной ущерба, наносимого в случае нару
шения конфиденциальности, целостности или до
ступности этого ресурса. В ходе оценки стоимости
ресурсов определяется величина возможного ущер
ба для каждой категории ресурсов:
•Данные были раскрыты, изменены, удалены или
стали недоступны.
•Аппаратура была повреждена или разрушена.
•Нарушена целостность ПО.
Типичные угрозы безопасности включают в себя:
•локальные и удаленные атаки на ресурсы АС;
•стихийные бедствия;
•ошибки персонала;
•сбои в работе АС, вызванные ошибками в ПО
или неисправностями аппаратуры.
Под уровнем угрозы понимается вероятность
ее осуществления.
Оценка уязвимостей предполагает определе
ние вероятности успешного осуществления угроз
безопасности. Успешное осуществление угрозы оз
начает нанесение ущерба ресурсам АС. Наличие
уязвимостей в АС обусловлено слабостями защиты.
Таким образом, вероятность нанесения ущер
ба определяется вероятностью осуществления угро
зы и величиной уязвимости.
Величина риска определяется на основе стои
мости ресурса, уровня угрозы и величины уязвимо
сти. Сувеличением стоимости ресурса, уровня угро
зы и величины уязвимости возрастает и величина
риска. На основе оценки величины рисков опреде
ляются требования безопасности.
Задача управления рисками включает выбор
и обоснование выбора контмер, позволяющих сни
зить величину рисков до приемлемого уровня. Уп
равление рисками включает в себя оценку стоимос
ти реализации контрмер, которая должна быть
меньше величины возможного ущерба. Разница
между стоимостью реализации контмер и величи
ной возможного ущерба должна быть тем больше,
чем меньше вероятность причинения ущерба.
Контрмеры могут способствовать уменьше
нию величины рисков различными способами:
•уменьшая вероятность осуществления угроз бе
зопасности;
•ликвидируя уязвимости или уменьшая их вели
чину;
•уменьшая величину возможного ущерба;
•выявляя атаки и другие нарушения безопасности;
•способствуя восстановлению ресурсов АС, ко
торым был нанесен ущерб.
При выполнении работ по анализу и управле
нию рисками в компании Инфосистемы Джет ис
пользуется методика CRAMM и соответствующие
инструментальные средства. Метод CRAMM (the UK
Government Risk Analysis and Management Method)
используется начиная с 1985 г. правительственными
и коммерческими организациями Великобритании.
За это время он приобрел популярность во всем мире.
CRAMM предполагает разделение всей про
цедуры на три последовательных этапа. Задачей
первого этапа является ответ на вопрос: «Достаточ
но ли для защиты системы применения средств ба
зового уровня, реализующих традиционные функ
ции безопасности, или необходимо проведение бо
лее детального анализа защищенности?». На втором
этапе производится идентификация рисков и оце
нивается их величина. На третьем этапе решается
вопрос о выборе адекватных контрмер.
Методика CRAMM для каждого этапа опреде
ляет набор исходных данных, последовательность ме
роприятий, анкеты для проведения опросов, списки
проверки и набор выходных документов (отчетов).
Единые критерии оценки безопасно
сти информационных технологий
В основе аттестации АС в настоящее время
лежат «Единые критерии оценки безопасности ИТ»
(Common Criteria for Information Technology Security
Evaluation). «Единые критерии» – это нормативный
документ, определяющий требования безопаснос
ти, на основании которых проводится оценка уров
ня защищенности продуктов ИТ, общий набор по
нятий, структур данных и язык для формулирова
ния вопросов и утверждений относительно безопас
ности продуктов ИТ.
Международная организация по стандартиза
ции (ISO) начала разработку критериев оценки за
щищенности в 1990 году. Затем авторы канадского
(CTCPEC), европейского (ITSEC) и американских
(FC и TCSEC) критериев оценки защищенности в
1993 году объединили свои усилия и начали разра
ботку проекта «Единых критериев». Целью проекта
было устранение концептуальных и технических
различий между существующими критериями. 1 де
кабря 1999 года версия 2.1 «Единых критериев» бы
ла принята ISO в качестве международного стандар
та ISO 15408.
Общее описание процедуры аттестации автоматизированных систем
В «Единых критериях» определен ряд ключе
вых понятий, лежащих в основе концепции оценки
защищенности продуктов ИТ. Среди них понятие
Профиля защиты (PP – Protection Profile), Задания
по безопасности (ST – Security Target) и Объекта
оценки (TOE – Target of Evaluation). В качестве Объ
екта оценки может выступать любое СВТ или АС.
PP представляет собой жестко структуриро
ванный документ, содержащий требования безо
пасности для определенного класса программно
технических средств. Помимо требований безопас
ности PP описывает множество угроз безопасности
и задач защиты, а также содержит обоснование со
ответствия между угрозами безопасности, задачами
защиты и требованиями безопасности.
ST представляет собой жестко структуриро
ванный документ, определяющий, помимо требова
ний безопасности, функциональную спецификацию
механизмов безопасности конкретного продукта
ИТ. Содержащиеся в ST требования безопасности
определяются при помощи ссылок на соответствую
щие Профили защиты и требования «Единых крите
риев». Специфичные для конкретного продукта ИТ
требования формулируются отдельно и также вклю
чаются в ST. Кроме этого, ST содержит обоснование
соответствия между требованиями безопасности и
функциональной спецификацией TOE.
В «Единых критериях» представлены две кате
гории требований безопасности: функциональные
требования и требования адекватности (гарантирован
ности) механизмов безопасности. Функциональные
требования определяют совокупность функций TOE,
обеспечивающих его безопасность. Адекватность –
это свойство TOE, дающее определенную степень уве
ренности в том, что механизмы безопасности TOE до
статочно эффективны и правильно реализованы. Вы
воды об адекватности TOE делаются на основании зна
ний о спецификации, реализации и функционирова
нии TOE. Для выражения функциональных требова
ний и требований адекватности в«Единых критериях»
используется единая терминология и стиль.
Аттестация – сложный, длительный и очень
ресурсоемкий процесс. Изза невозможности про
извести формальную верификацию или исчерпыва
ющее тестирование всей АС, приходится говорить
лишь о достижении определенного уровня адекват
ности (гарантированности) результатов аттестаци
онных испытаний. В «Единых критериях» вводится
единая шкала уровней адекватности оценки (EAL –
Evaluation Assurance Level). Каждый EAL представ
лен определенной совокупностью требований адек
ватности «Единых критериев».
Вводится семь уровней адекватности оценки:
EAL1, EAL2, …, EAL7. Эти уровни упорядочены по
возрастанию. Минимальный уровень адекватности
– EAL1 (функциональное тестирование) предостав
ляет минимальные гарантии адекватности путем
проведения анализа механизмов безопасности с ис
пользованием спецификаций функций и интерфей
са TOE, сопровождаемого независимым тестирова
нием каждого механизма безопасности по методу
«черного ящика». EAL1 предназначен для обнару
жения только самых очевидных уязвимостей защи
ты при минимальных издержках. Он применим в
тех случаях, когда отсутствуют серьезные риски,
связанные с безопасностью. Максимальный уро
вень адекватности – EAL7 (формальная верифика
ция проекта и тестирование) характеризуется ис
пользованием при проектировании комплекса
средств защиты формальной модели, формального
представления функциональных спецификаций,
полуформального представления проекта нижнего
уровня и формальной или полуформальной демон
страции соответствия между ними. Анализы сопро
вождаются независимым тестированием механиз
мов безопасности по методу «белого ящика». Уро
вень EAL7 представляет верхнюю границу уровней
адекватности оценки АС, которую реально достичь
на практике. Его использование следует рассматри
вать только в качестве экспериментального для атте
стации простых и особо критичных АС.
Согласно «Единым критериям» этапы оценки
защищенности TOE определяются, исходя из раз
личных уровней абстракции представления: угрозы
безопасности —> задачи защиты —> требования бе
зопасности —> спецификация —> реализация.
Выделяют два основных этапа проведения
оценивания:
1.Оценка базовых Профилей защиты.
2.Анализ Объекта оценки.
Оценка базовых Профилей защиты включает
анализ угроз безопасности, задач защиты, требований
безопасности и установку соответствия между ними.
Анализ Объекта оценки проводится в два эта
па: Оценка Задания по безопасности и Оценка TOE.
Оценка Задания по безопасности имеет це
лью демонстрацию того, что спецификация (фор
мальное, полуформальное или неформальное опи
сание) механизмов безопасности полностью отвеча
ет требованиям Профиля защиты и является при
годным для использования в качестве основы для
оценивания TOE;
Оценка TOE заключается в проверке соответ
ствия реализации TOE его спецификации, содержа
щейся в Задании по безопасности.
Анализ механизмов безопасности
Используемая методика анализа механизмов
безопасности зависит от того, имеется ли четко оп
ределенный набор требований безопасности либо
по тем или иным причинам он отсутствует.
Когда требования безопасности определены
Когда требования безопасности определены
и задокументированы, основной задачей этапа базо
Александр Астахов
вого анализа становится проверка соответствия ре
ализованных в АС механизмов безопасности этим
требованиям. При проведении испытаний АС ис
пользуются списки проверки, которые содержат,
например, следующие вопросы: Обеспечен ли инди
видуальный учет пользователей? Идентифицирова
ны ли субъекты и объекты и присвоены ли им метки
доступа? Обеспечивается ли режим доступа к дан
ным «только на чтение»? Выполняется ли регистра
ция всех попыток доступа к файлам? Имеются пла
ны восстановления работоспособности и реагирова
ния на попытки НСД? и т. п.
Требования безопасности могут быть сфор
мулированы с различной степенью детализации. В
некоторых случаях требования только определяют
необходимость наличия некоторого механизма бе
зопасности, например, такого, как аутентификация
удаленных пользователей. В других случаях требо
вания могут определять необходимость использова
ния конкретной схемы аутентификации. В обоих
ситуациях проверяется наличие соответствующих
механизмов безопасности и их адекватность суще
ствующим угрозам.
Когда требования безопасности не определены
Бывают ситуации, когда требования безопас
ности не могут быть четко определены. Например,
когда требуется обеспечить защиту ресурсов корпо
ративной сети от сетевых атак, то практически невоз
можно идентифицировать все способы возможных
атак, от которых требуется защищаться. В таких ситу
ациях целесообразно использовать методы активного
тестирования механизмов безопасности АС. Эти ме
тоды основаны на оценке эффективности противо
действия механизмов безопасности определенным
видам угроз. Например, активное тестирование меха
низмов контроля доступа выполняется путем осуще
ствления попыток проникновения в систему (с помо
щью автоматического инструментария или вручную).
Для поиска известных уязвимостей защиты АС ис
пользуются различные автоматизированные средства
анализа защищенности, наиболее распространенны
ми из которых являются сетевые сканеры.
Большинство методов оценки требований бе
зопасности также годятся и в данной ситуации. Одна
ко, без четко сформулированных требований трудно
определить адекватность механизмов безопасности.
Уровень детализации
Важным вопросом анализа механизмов безо
пасности является выбор уровня детализации. В об
щем случае базовый анализ должен выполняться на
функциональном уровне. Функциональный уро
вень – это уровень абстракции, представленный
спецификациями функций АС. Это относится как к
внутренним механизмам безопасности, так и к
внешним (физическим и административным мерам
защиты), хотя последние обычно не определяются в
функциональных спецификациях.
Для многих АС функциональных специфика
ций просто не существует, либо они бывают непол
ны. Поэтому экспертам для того, чтобы определить
функциональные спецификации АС, приходится
изучать принципы ее функционирования, проект
ную и эксплуатационную документацию.
Проверка существования механиз
мов безопасности
На этапе базового анализа проверяется суще
ствование механизмов безопасности, представлен
ных функциональными спецификациями АС. Уста
новить факт существования большинства физичес
ких и административных мер защиты можно про
стой визуальной проверкой и проверкой наличия
соответствующей организационнораспорядитель
ной документации. Для проверки наличия механиз
мов безопасности, реализованных программными
или техническими средствами, необходимо прове
дение тестирования. При тестировании не ставится
задача определения качества функционирования
защитных механизмов, т. к. это выходит за рамки
базового анализа. С другой стороны, в случае нали
чия серьезных недостатков, ставящих под вопрос
общую эффективность комплекса средств защиты
АС, качество реализации защитных механизмов
должно учитываться. Обычно для проверки наличия
механизмов безопасности бывает достаточно про
ведения тестирования по методу «черного ящика».
Обзор методологии реализации
механизмов безопасности
Проверка существования механизмов безо
пасности не дает гарантий эффективности функци
онирования этих механизмов. Лучшим способом
получить определенные гарантии, не погружаясь в
тестирование и детальные анализы, является рас
смотрение методологии, использовавшейся при раз
работке АС. Рассмотрение методологии произво
дится независимо от того, находится ли АС на этапе
разработки или эксплуатации.
Обзор методологии позволяет судить о степе
ни надежности реализации механизмов безопасно
сти и о вероятности наличия брешей в защите АС.
Недостатки используемых методов проектирования
и разработки приводят к ошибкам в реализации АС.
Если в результате анализа методологии установле
но, что качеству реализации доверять нельзя, то,
обычно, требуется проведение детального анализа
для поиска конкретных ошибок в реализации АС.
Американские источники, посвященные ме
тодологии разработки средств защиты информа
ции, содержат множество государственных стан
дартов, устанавливающих порядок разработки и
анализа защищенности критичных АС и ПО.
Общее описание процедуры аттестации автоматизированных систем
В нашей стране Гостехкомиссией РФ был
принят РД «Временное положение по организации
разработки, изготовления и эксплуатации про
граммных и технических средств защиты информа
ции от НСД в АС и СВТ», определяющий следую
щие основные вопросы:
•организационную структуру и порядок прове
дения работ по защите информации от НСД и
взаимодействия при этом на государственном
уровне;
•систему государственных нормативных актов,
стандартов, руководящих документов и требо
ваний по этой проблеме;
•порядок разработки и приемки защищенных
СВТ, в том числе программных и технических (в
частности, криптографических) средств и сис
тем защиты информации от НСД;
•порядок приемки указанных средств и систем
перед сдачей в эксплуатацию в составе АС, по
рядок их эксплуатации и контроля за работо
способностью этих средств и систем в процессе
эксплуатации.
Повышенное внимание во время обзора ме
тодологии уделяется следующим вопросам:
1.Полнота и качество проектной и эксплуатаци
онной документации.
2.Наличие четко определенных требований к про
ектированию АС.
3.Используемые методы управления проектом.
Наличие у разработчиков методики анализа и
тестирования механизмов безопасности АС.
4.Используемые в процессе создания АС методы
пректирования. Учет основных принципов ар
хитектурной безопасности. Используемые стан
дарты и технологии программирования.
5.Осведомленность разработчиков АС в вопросах
информационной безопасности. Учет требова
ний безопасности на этапах проектирования и
реализации.
Детальный анализ
Во многих случаях для проведения аттестации
бывает недостаточно одного базового анализа. При
мерами могут служить случаи, при которых (1) во
время базового анализа обнаруживаются пробле
мы, требующие проведения дальнейших исследова
ний; (2) АС имеет высокую степень критичности;
или (3) основные механизмы безопасности встрое
ны во внутренние функции, которые не видны на
функциональном уровне. В подобных случаях тре
буется проведение детального анализа.
Детальный анализ концентрируется на оцен
ке эффективности реализации механизмов безо
пасности. АС исследуется с трех точек зрения:
1.Оценка правильности функционирования ме
ханизмов безопасности.
2.Оценка эксплуатационных характеристик, та
ких как надежность и производительность.
3.Оценка устойчивости к попыткам взлома.
При детальном анализе используется множе
ство подходов, выбор которых определяется скорее
существующими угрозами и их последствиями, чем
общими характеристиками и критичностью АС. На
пример, если главной задачей является обеспечение
конфиденциальности закрытой информации, основ
ной упор делается на контроле доступа к этой ин
формации и закрытии ее содержания при помощи
криптографических средств. Организации, предо
ставляющие пользователям критичные сервисы,
должны сконцентрировать свои усилия, прежде все
го, на вопросах доступности этих сервисов. Если
главной задачей приложения является обработка
клиентских счетов, то особое внимание должно быть
уделено механизмам контроля целостности данных.
Подходы к проведению детального
анализа
Проверка правильности функционирования меха
низмов безопасности
При проверке правильности функционирова
ния механизмов безопасности ставится задача оце
нить, выполняют ли защитные механизмы возло
женные на них функции. Наиболее часто для реше
ния этой задачи используются различные методы
тестирования.
При тестировании защитных механизмов
изучаются следующие вопросы:
1.Работоспособность механизмов безопасности.
2.Проверка правильности обработки недопусти
мых параметров функций.
3.Обработка исключительных ситуаций.
4.Мониторинг механизмов безопасности и регис
трация событий, связанных с безопасностью.
5.Проверка правильности функционирования
средств администрирования.
Механизмы безопасности АС должны быть
адекватно защищены как от ошибок пользователей,
так и от внутренних ошибок. Следовательно, при те
стировании особое внимание должно уделяться сис
темным интерфейсам, через которые могут распро
страняться эти ошибки:
1.человекчеловек (сообщения оператора);
2.человексистема (команды, процедуры);
3.системасистема (внутренние функции системы);
4.процесссистема (системные вызовы);
5.процесспроцесс (межпроцессорное взаимодей
ствие).
Здесь может использоваться большинство из
вестных методов тестирования. Тестирование мо
жет быть либо внешним (метод «черного ящика»),
либо внутренним (метод «белого ящика», тестирова
Александр Астахов
ние отдельных программных модулей и связей меж
ду модулями), в зависимости от типа интерфейса,
который подвергается тестированию. Тестирование
может быть выполнено группой экспертов, прово
дящих анализ, разработчиками, пользователями или
смешанным коллективом.
Когда тестирование внутренних интерфейсов
выполняется независимо от разработчика АС, оно
может быть связано с определенными техническими
проблемами. Может потребоваться написание фик
тивных подпрограмм (пустышек), инструментарий
для генерации и сбора тестовых данных и множест
во вспомогательного программного обеспечения.
Может потребоваться инструментарий для разра
ботки ПО, специально приспособленный для кон
кретной ОС или конкретной АС. Идеальным реше
нием является использование средств, при помощи
которых АС первоначально разрабатывалась.
Помимо тестирования, существуют также
другие методы анализа, которые можно использо
вать для проверки правильности функционирова
ния механизмов безопасности.
В качестве одного из методов при проведении
детального анализа может использоваться формаль
ная верификация. Формальная верификация дает
возможность математически точно доказать соответ
ствие реализации функций безопасности АС на язы
ке программирования ее формальной спецификации.
Представляется весьма перспективным ис
пользование автоматизированных систем доказа
тельства корректности программ. К настоящему
времени существует уже более двадцати подобных
систем. Каждая из этих систем разрабатывалась для
верификации широкого класса программ опреде
ленной предметной области. В их основе лежат раз
ные математические аппараты и разные принципы
Общее описание процедуры аттестации автоматизированных систем
1. Ресурсы
2. Угрозы
3. Последствия
угроз
4. Механизмы
безопасности
Детальное
рассмотрение
компонентов
модели
защиты
Проверка правильности
функционирования механизмов
безопасности
Оценка эксплуатационных
характеристик
Тестирование при пиковых нагрузках
Анализ устойчивости к попыткам взлома
Поиск уязвимостей, попадающих
в определенные категории
Построение и проверка
гипотез об уязвимостях
1. Тестирование
2. Валидация
3. Верификация
Анализ сценариев
атак и процессов АС
Выбор
стратегии
Детальный анализ
Рис. 4. Детальный анализ механизмов безопасности АС
функционирования. Однако можно выделить ком
поненты, необходимые любой подобной системе:
1.Язык формальной спецификации.
На этом языке описываются входные и вы
ходные данные (структуры данных, абст
рактные типы данных).
2.Язык программирования.
На этом языке пишется программа. Для то
го, чтобы правильность этой программы
можно было доказать, семантика этого язы
ка должна быть формально определена.
3.Блок синтаксического анализа.
На вход этого блока поступает уже анноти
рованная программа, т. е. программа на
языке программирования вместе с ее спе
цификацией на языке спецификации. Блок
синтаксического анализа осуществляет
синтаксический контроль и преобразует
программу к специальному виду, удобному
для дальнейшей обработки.
4.Генератор условий корректности (генератор те
орем).
Выдает список условий корректности на
вход блока доказательства. Реализует алго
ритмы обратного и прямого прослеживания.
5.Блок доказательства теорем.
Является наиболее сложным. Он выдает
список упрощенных условий корректности
на вход блока анализа выхода, среди кото
рых выделены доказанные условия. Блок
доказательства имеет дополнительный
вход, на который подается информация от
пользователя в виде аксиом.
6.Блок анализа выходных данных.
Осуществляет, совместно с пользователем,
анализ списка условий корректности. Если
все условия доказаны, то входная програм
ма частично корректна.
Например, система FDM позволяет пользова
телю написать спецификацию формальной модели
(включая инварианты и ограничения по безопасно
сти) на языке спецификации Ina Jo, а генератор тео
рем автоматически генерирует теоремы (критерий
правильности), которые должны быть доказаны,
чтобы гарантировать, что спецификация верхнего
уровня соответствует модели. Генератор теорем
также автоматически генерирует теоремы, которые
необходимо доказать, чтобы гарантировать, что спе
цификация каждого нижележащего уровня следует
из спецификации более высокого уровня.
Система AFFIRM доказывает корректность
программ на языке Паскаль, расширенных за счет
абстрактных типов данных. Основная особенность
системы – использование базы данных и модуля
доказательства в эквациональных теориях на осно
ве алгоритма КнутаБендикса. Модуль применяется
для доказательства свойств абстрактных типов дан
ных, аксиоматизированных посредством равенств.
База данных используется для хранения аксиом и
свойств абстрактных типов данных, установленных
с помощью канонических систем подстановок тер
мов, а также для хранения промежуточных утверж
дений, возникающих в процессе доказательства ус
ловий корректности. Система AFFIRM включает
также модуль доказательства теорем в процессе ди
алога с пользователем, который выбирает страте
гию доказательства. Этот модуль базируется на уни
версальном методе доказательства теорем (метод ес
тественного вывода, включающий правило индук
ции) и в процессе работы использует информацию
из базы данных. Задача синтеза инвариантов цик
лов в этой системе возлагается на пользователя.
Существуют успешные примеры примене
ния автоматизированных систем доказательства
корректности программ для верификации механиз
мов безопасности. Например, в проекте защищен
ной операционной системы UNIX, выполненном в
Калифорнийском университете в городе ЛосАнже
лес (UCLA), для проверки механизмов защиты дан
ных от несанкционированного доступа использова
лись методы формальной спецификации и верифи
кации. В этом проекте для доказательства правиль
ности программного кода использовался генератор
условий корректности для языка Паскаль системы
AFFIRM. Доказательства условий правильности
уровня проектирования были выполнены вручную,
однако, система AFFIRM использовалась для про
верки части этих доказательств.
Формальные методы изза своей трудоемкос
ти, высокой стоимости и недостаточной изученнос
ти пока не получили широкого распространения.
Однако, они используются при разработке и вери
фикации механизмов контроля вооружений, косми
ческих аппаратов и других АС, связанных с высо
ким риском. Эти методы в перспективе будут играть
более важную роль при проведении аттестации.
Оценка эксплуатационных характеристик
Эффективность механизмов безопасности
определяется не только корректностью их функци
онирования. Многие показатели, определяющие
эффективность, можно отнести к общей категории
под названием «эксплуатационные характеристи
ки», которая является второй областью исследова
ния при детальном анализе. К показателям эффек
тивности относятся: надежность, отказоустойчи
вость, восстанавливаемость, время реакции и про
изводительность. Они применимы как к отдельным
механизмам, так и к АС в целом.
Тестирование является лучшим способом
оценки эксплуатационных характеристик, при этом
для измерения каждого показателя эффективности
необходимы специальные виды тестов. Употреби
тельным методом является тестирование на пико
вых нагрузках. Для создания пиковых нагрузок тре
буется создание множества запросов на обслужива
Александр Астахов
ние, использование большого количества фоновых
процессов и задействование максимального количе
ства системных ресурсов. Этот метод годится и для
тестирования механизмов безопасности, т. к. в про
цессе эксплуатации пиковые нагрузки часто пере
межаются с нормальной работой.
Тестирование при пиковых нагрузках также ис
пользуется в более направленной манере, путем осуще
ствления попыток исчерпать квоты на использование
конкретных системных ресурсов, таких как буферы,
очереди, таблицы, порты и т. п. Направленное тестиро
вание при пиковых нагрузках особенно полезно при
оценке устойчивости АС к отказам вобслуживании.
Устойчивость к попыткам взлома
При использовании этого подхода ставится за
дача оценить устойчивость механизмов безопаснос
ти АС к попыткам их взлома или обхода. Устойчи
вость – это способность АС блокировать и оператив
но реагировать на возможные атаки. Методы крипто
анализа, например, могут использоваться для взлома
конкретного механизма безопасности – шифрова
ния. Создание и использование перехватчика паро
лей – это пример обхода механизмов безопасности.
Используемые методы анализа устойчивости
АС определяются моделью нарушителя. В соответст
вии с моделью нарушителя обычно все потенциаль
ные нарушители делятся на две категории: внешние
и внутренние. В качестве внутреннего нарушителя
рассматривается субъект, имеющий доступ к работе
со штатными средствами АС и СВТ как части АС. На
рушители классифицируются по уровню возможно
стей, предоставляемых им штатными средствами АС
и СВТ. Выделяется четыре уровня этих возможнос
тей. Классификация является иерархической, т.е.
каждый следующий уровень включает в себя функ
циональные возможности предыдущего.
Первый уровень (уровень пользователя) опре
деляет самый низкий уровень возможностей веде
ния диалога в АС – запуск задач (программ) из фик
сированного набора, реализующих заранее предус
мотренные функции по обработке информации.
Второй уровень (уровень прикладного про
граммиста) определяется возможностью создания и
запуска собственных программ с новыми функция
ми по обработке информации.
Третий уровень (уровень администратора)
определяется возможностью управления функцио
нированием АС, т.е. воздействием на базовое про
граммное обеспечение системы, на состав и конфи
гурацию ее оборудования.
Четвертый уровень (уровень системного про
граммиста или разработчика АС) определяется всем
объемом возможностей лиц, осуществляющих про
ектирование, реализацию и ремонт технических
средств АС, вплоть до включения в состав СВТ соб
ственных технических средств с новыми функция
ми по обработке информации.
Общее описание процедуры аттестации автоматизированных систем
Преобразованная
программа
Блок
синтаксичес
кого анализа
Блок
генерации
условий
корректности
Аннотир.
программа
(Вход
системы)
Блок
доказательства
Блок
анализа
выходных
данных
(Дополнительный
вход системы)
Аксиомы
пользователя
Условия
корректности
Недоказанные условия
корректности
Упрощенные
условия
корректности
Доказана
частичная
корректность
программы
(Выход)
Модифицированная
программа
Рис. 5. Обобщенная схема автоматизированной системы доказательства корректности программ
Внешние нарушители по уровню своих воз
можностей также могут подразделяться на уровни.
В своем уровне нарушитель является специа
листом высшей квалификации, знает все об АС и, в
частности, о системе и средствах ее защиты.
Понятие устойчивости к попыткам взлома от
носится не только к атакам на данные, но также к
атакам, направленным против физических и про
граммных ресурсов АС.
Оценка устойчивости к попыткам взлома мо
жет оказаться технически наиболее сложной зада
чей при детальном анализе. Эта часть анализа про
изводится с целью повышения уровня гарантиро
ванности, а также поиска и устранения брешей в за
щите АС. Однако, опыт показывает неадекватность
метода «найти и устранить» для обеспечения безо
пасности. Здесь выделяются три задачи:
1.Оценка устойчивости АС к попыткам взлома.
2.Определение величины уязвимостей (с какими
трудностями связано использование брешей в
защите).
3.Демонстрация возможностей использования
брешей в защите.
Существует несколько подходов к анализу ус
тойчивости АС:
1.Поиск уязвимостей, попадающих в определен
ную категорию или соответствующих опреде
ленному шаблону.
2.Построение гипотезы о наиболее характерных
уязвимостях и определение того, существуют ли
они в данной программе.
Хотя эти подходы применяются при анализе
программного обеспечения, существуют аналогич
ные подходы к анализу технических средств, а так
же физических и административных механизмов
безопасности.
Стратегии сосредоточения усилий
при детальном анализе
Даже при детальном анализе редко удается ох
ватить целиком все аспекты обеспечения безопасно
сти АС. Ниже представлены две стратегии сосредото
чения усилий, которые применяются при проведе
нии анализа с использованием обсуждавшихся выше
подходов. Одна основана на анализе компонентов
модели защиты, а другая – на анализе конкретных
сценариев атак и процессов, происходящих в АС.
Анализ компонентов модели защиты АС
Эта стратегия сосредоточения усилий базиру
ется на четырех основных компонентах модели защи
ты АС, в число которых входят ресурсы, угрозы, воз
можные последствия угроз и механизмы безопаснос
ти. Все эти компоненты должны быть уже рассмотре
ны на этапе базового анализа и в ходе анализа рисков.
Текущая задача предполагает их более детальное рас
смотрение на основе уже имеющихся данных.
Информационные, программные и физичес
кие ресурсы АС выступают в качестве объекта за
щиты. Может потребоваться произвести детальное
исследование ресурсов (файлов, записей, программ,
устройств, каналов связи и т. п.) вместе с их атрибу
тами (количество, параметры, способы использова
ния, характеристики).
Угрозы безопасности для ресурсов АС опреде
ляются в терминах модели нарушителя, способа осу
ществления угрозы и объекта нападения. При анали
зе угроз важно различать виды угроз: случайные, на
меренные или обусловленные естественными при
чинами. Защита от намеренных угроз, называемых
также атаками, может оказаться наиболее сложной.
Атаки на ресурсы АС, предпринимаемые как
внешними, так и внутренними нарушителями, под
разделяются на удаленные (сетевые) и локальные.
Локальные атаки характеризуются следую
щими атрибутами:
1.Источник угрозы, описываемый моделью нару
шителя.
2.Вид атаки, указывает на принадлежность к тому
или иному известному виду атак, согласно их
классификации.
3.Способ атаки, указывает на принадлежность к
тому или иному известному способу атаки дан
ного вида, согласно их классификации.
4.Объект атаки (ресурс АС, против которого на
правлена атака).
5.Цель и последствия (результат) осуществления
угрозы (описание последствий и оценка вероят
ного ущерба). Возможными целями осуществ
ления угроз безопасности являются нарушение
конфиденциальности, целостности или доступ
ности информационных ресурсов АС, а также
доступности программных и технических ком
понентов АС.
6.Условия (предпосылки) возникновения угрозы
безопасности, такие как наличие определенных
видов уязвимостей, нарушения технологичес
кого процесса проектирования и разработки
ПО и т. п.
7.Жизненный цикл угрозы, который состоит из
следующих процессов:
• зарождение,
• развитие,
• проникновение в АС,
• проникновение в критичную информацию,
• инициализация,
• результат действия,
• регенерация.
Удаленные (сетевые) атаки дополнительно
могут характеризоваться следующими атрибутами:
1.Условие начала осуществления воздействия:
• Атака по запросу от атакуемого объекта.
Александр Астахов
• Атака по наступлению ожидаемого собы
тия на атакуемом объекте.
• Безусловная атака.
2.По наличию обратной связи с атакуемым объ
ектом:
• С обратной связью.
• Без обратной связи.
3.По расположению субъекта атаки относитель
но атакуемого объекта:
• Внутрисегментное.
• Межсегментное.
4.По уровню эталонной модели OSI, на котором
осуществляется воздействие:
• Физический.
• Канальный.
• Сетевой.
• Транспортный.
• Сеансовый.
• Представительский.
• Прикладной.
5.По характеру воздействия:
• Активное.
• Пассивное.
В процессе анализа исследуются факторы, вли
яющие на вероятности успешного осуществления уг
роз. Вероятности осуществления угроз зависят от со
стояния и степени критичности ресурсов, последст
вий, связанных с реализацией угрозы, существую
щих защитных механизмов и ожидаемого выигрыша,
получаемого злоумышленником. Вероятности успеш
ного осуществления угроз зависят от величины уязви
мостей защиты АС, которые также оцениваются.
На выбор методов анализа оказывает влияние
природа угроз. Например, стандартным является
метод анализа исходных текстов программы с це
лью определения их соответствия установившейся
технологии и стилю программирования, поиска
ошибок и брешей в реализации механизмов безо
пасности. Однако, если источником угрозы является
разработчик приложения, то встает задача поиска
программных закладок и, вместо исходных текстов
и спецификации, проводится изучение объектного
кода, т.к. злонамеренные действия разработчика в
этом случае не будут задокументированы.
Последствия реализации угроз – это формы
возможных потерь, характеризуемые величиной
ущерба, наносимого владельцу или пользователям
АС. Примерами последствий реализации угроз мо
гут служить раскрытие конфиденциальной инфор
мации, принятие ошибочных решений руководст
вом организации и кража денежных средств путем
компьютерного мошенничества. При оценке воз
можного ущерба рассматривается наихудший вари
ант развития событий.
Анализ механизмов безопасности предполага
ет детальное исследование эффективности их проти
водействия угрозам. На этом этапе осуществляется
поиск слабостей механизмов безопасности, которые
обуславливают существование уязвимостей защиты,
определение реальных трудностей, связанных с ис
пользованием слабостей конкретного механизма бе
зопасности, анализ накладных расходов на обеспече
ние безопасности и исследование альтернативных
способов реализации защитных механизмов.
Анализ конкретных сценариев атак
и процессов
Размеры и сложность современных АС часто
не позволяют получить исчерпывающую информа
цию обо всех аспектах ее функционирования. В
этом случае оценку уровня защищенности АС при
ходится давать, основываясь на неполной информа
ции. Эффективным решением в данной ситуации
является использование подхода, связанного с ана
лизом конкретных сценариев атак и процессов, про
исходящих в АС. Данный подход дополняет резуль
таты базового анализа конкретными примерами, и
позволяет сосредоточиться на частных и наиболее
важных аспектах работы отдельных приложений.
Сценарий атаки описывает стадии реализа
ции угрозы безопасности, рассмотренные выше.
Примером сценария атаки может служить пошаго
вое описание попытки несанкционированного про
никновения в АС (включая последовательность дей
ствий злоумышленника и процесс планирования
атаки), используемых уязвимостей, скомпромети
рованных ресурсов АС и последствий атаки (вклю
чая оценку ущерба).
Данный подход предполагает широкое исполь
зование методов активного тестирования защищенно
сти АС с применением соответствующих инструмен
тальных средств. Идея активного тестирования заклю
чается в имитации действий возможного злоумыш
ленника по преодолению системы защиты с использо
ванием известных методов осуществления локальных
и удаленных атак. По результатам тестирования дела
ется вывод о наличии либо отсутствии в АС известных
уязвимостей. На данном принципе основана работа
сетевых сканеров, являющихся в настоящее время ос
новным инструментом активного тестирования АС.
Подготовка отчетных документов
по результатам аттестации
Основными отчетными документами по ре
зультатам аттестации являются Заключение и прила
гаемый к нему Протокол аттестационных испыта
ний. Заключение содержит выводы относительно со
ответствия механизмов безопасности АС критериям
аттестации, оценку уровня защищенности и реко
мендации по обеспечению режима информацион
Общее описание процедуры аттестации автоматизированных систем
ной безопасности АС, дополняющие существующие
организационные меры защиты. Заключение осно
вывается на данных, содержащихся в Протоколе ат
тестационных испытаний. На основании Заключения
председатель аттестационной комиссии принимает
решение о выдаче Аттестата соответствия.
Содержание отчетных документов
В американских руководящих документах
предлагается следующая структура итогового отчета:
1.Введение и краткое содержание. Коротко опи
сываются назначение, основные характеристи
ки и особенности исследуемой АС, делаются вы
воды по результатам базового и детального ана
лизов и даются рекомендации по устранению за
меченных недостатков в организации защиты.
2.Описание объекта оценки. Этот раздел содер
жит информацию, необходимую для принятия
решения о возможности выдачи Аттестата соот
ветствия, разрешающего обработку в АС ин
формации заданной степени критичности. Од
ним из основных вопросов здесь является соот
ветствие АС стандартам, нормативным доку
ментам и требованиям политики безопасности.
Также в данном параграфе описываются харак
теристики АС, влияющие на принятие решения
о выдаче аттестата, ограничения, накладывае
мые на использование АС, и ее границы.
3.Результаты аттестационных испытаний. В пер
вой части этого раздела описываются механиз
мы безопасности АС и их роль в противодейст
вии существующим угрозам безопасности. Во
второй части раздела дается описание уязвимо
стей АС, которые делятся на две категории: ос
таточные уязвимости, которые по экономичес
ким соображениям можно оставить, и уязвимо
сти, которые необходимо ликвидировать. Эта
часть раздела служит одновременно кратким
изложением результатов анализа и рекоменда
цией по ликвидации обнаруженных уязвимос
тей или принятию остаточных рисков.
4.Мероприятия по устранению недостатков сис
темы защиты. В этом разделе описываются ме
роприятия по устранению уязвимостей, оцени
вается стоимость реализации контрмер и их
влияние на работу АС, а также расставляются
приоритеты на выполнение указанных задач.
К итоговому отчету прилагаются следующие
документы:
•Протокол аттестационных испытаний.
•Заключение по результатам аттестации с указа
нием возможности обработки в АС информации
заданного уровня критичности.
•отчеты по результатам предварительного обсле
дования АС, базового и детального анализов.
В случае несоответствия АС предъявляемым к
ней требованиям по безопасности информации и
невозможности оперативно устранить выявленные
недостатки может быть принято решение об отказе
в выдаче аттестата. При этом может быть назначен
срок проведения повторной аттестации.
При наличии замечаний непринципиального
характера Аттестат может быть выдан после провер
ки устранения этих замечаний.
Многие уязвимости защиты, выявленные при
аттестации, не могут являться достаточным основа
нием для отказа в выдаче Аттестата. В подобной си
туации для закрытия брешей в программнотехни
ческой защите АС возможно использование различ
ных контрмер организационного уровня, перечень
которых обязательно указывается в Аттестате соот
ветствия. Примерами подобных контрмер могут
служить запрещение осуществления удаленного до
ступа к ресурсам АС по коммутируемым каналам
связи в приказном порядке, ограничение уровня
конфиденциальности информации, разрешенной
для обработки в АС, изъятие из состава АС наиболее
уязвимых ее компонентов и т. п.
Планирование
Начало
Сбор информации
Базовый анализ
Детальный анализ
Составление отчета
по результатам аттестации
Да
Нет
Аккредитация
Конец
Информация о работе Общее описание процедуры аттестации автоматизированных систем по требованиям информационной безопасности