1 Предпроектная стадия
1.1 обследование объекта информатизации:
· установление необходимости обработки конфиденциальной информации на данном объекте информатизации;
· определение перечня сведений, подлежащих защите;
· определение условий расположения объектов информатизации относительно границ контролируемой зоны (КЗ);
· определение конфигурации и топологии автоматизированных систем (АС), информационных систем персональных данных (ИСПДн) и систем связи в целом и их отдельных компонент;
· определение технических средств и систем, используемых в защищаемой АС (ИСПДн) и системах связи, условий их расположения;
· определение общесистемных, специальных и прикладных программных средств, используемых в защищаемой АС (ИСПДн);
· определение режима обработки информации в АС (ИСПДн) в целом и в отдельных компонентах;
· проведение классификации АС (ИСПДн);
· определение степени участия персонала в обработке (обсуждении, передаче, хранении) информации, характер их взаимодействия между собой;
· определение и составление перечня уязвимостей и угроз безопасности информации, оценка актуальности угроз безопасности информации;
· разработка модели угроз безопасности информации.
1.2 разработка технического задания на создание СЗИ (СЗПДн):
· разработка аналитического обоснования необходимости создания СЗИ (СЗПДн);
· разработка требований по защите информации на основе действующих нормативных - методических документов по защите информации и персональных данных с учетом установленного класса защищенности АС (ИСПДн);
· разработка технического (частного технического) задания на разработку СЗИ (СЗПДн).
2 Стадия проектирования и реализации СЗИ (СЗПДн), включающая разработку СЗИ
2.1 разработка проекта на создание СЗИ (СЗПДн);
2.2 разработка организационно-технических мероприятий по защите информации в соответствии с предъявляемыми требованиями;
2.3 закупка сертифицированных средств защиты информации (СрЗИ);
2.4 разработка и реализация разрешительной системы доступа пользователей и персонала к защищаемой информации на объекте информатизации;
2.5 установка и настройка средств защиты информации (СрЗИ);
2.6 определение заказчиком подразделений и лиц, ответственных за эксплуатацию средств и мер защиты информации, обучение назначенных лиц специфике работ по защите информации на стадии эксплуатации объекта информатизации;
2.7 разработка эксплуатационной документации на объект информатизации и средства защиты информации, а также организационно-распорядительной документации по защите информации (положений, технических паспортов, приказов, инструкций и других документов);
2.8 выполнение других мероприятий, направленных на защиту информации.
3 Стадия ввода в действие СЗИ (СЗПДн)
3.1 опытная эксплуатация средств защиты информации в комплексе с другими техническими и программными средствами в целях проверки их работоспособности в составе объекта информатизации и отработки технологического процесса обработки (передачи) информации;
3.2 приемо-сдаточные испытания средств защиты информации по результатам опытной эксплуатации с оформлением приемо-сдаточного акта, подписываемого разработчиком (поставщиком) и заказчиком;
3.3 оценка соответствия СЗИ (СЗПДн) требованиям безопасности информации - аттестация объекта информатизации по требованиям безопасности информации.
4 Техническое обслуживание и сопровождения системы защиты информации
46. Разработка проекта комплексной системы защиты объекта информатизации согласно ГОСТ Р 51275-99: информационные ресурсы, средства обеспечения, помещения и выделенные объекты.
Выявление и учет факторов, воздействующих или могущих воздействовать на защищаемую информацию в конкретных условиях, составляют основу для планирования и осуществления эффективных мероприятий, направленных на защиту информации на ОИ.
Полнота и достоверность выявления факторов, воздействующих на защищаемую информацию, должны быть достигнуты путем рассмотрения полного множества факторов, воздействующих на все элементы ОИ (технические и программные средства обработки информации, средства обеспечения ОИ и т.д.) и на всех этапах обработки информации.
Выявление факторов, воздействующих на защищаемую информацию, должно быть осуществлено с учетом следующих требований:
- достаточности уровней классификации факторов, воздействующих на защищаемую информацию, позволяющей формировать их полное множество;
- гибкости классификации, позволяющей расширять множества классифицируемых факторов, группировок и признаков, а также вносить необходимые изменения без нарушения структуры классификации.
Основными методами классификации факторов, воздействующих на защищаемую информацию, являются иерархический и фасетный методы.
47. Процесс квалификационного анализа ИТ-продуктов с использованием профилей защиты и заданий по безопасности. ГОСТ Р 15408-2002 - структура и области применения, последовательность формирования требований и спецификаций: среда безопасности, цели безопасности, требования безопасности и краткая спецификация объекта оценки.
Основные понятия
Если попытаться кратко сформулировать главную концепцию "Общих критериев", то, скорее всего, она будет выглядеть как "угрозы и профили". Окружающий нас мир не просто не идеален, он опасен. И эксплуатируемые в нем комплексные системы и ПО буквально со всех сторон окружают угрозы. В зависимости от того, в каких условиях эксплуатируется конкретный ИТ-объект (например, подключена ли данная система к сетям общего пользования или функционирует автономно), к нему можно предъявить столь же конкретный перечень требований к защите, т. е. формализовать так называемый профиль защиты. Такие требования могут быть сформулированы пользователем в техническом задании на разработку или сформированы самостоятельно создателем системы или средства. В процессе сертификации некой системы по ОК сертифицирующий орган рассматривает документ, который называется " задание по безопасности ", - представляемый разработчиком системы в органы сертификации перечень требований к данной системе по безопасности. Сертификат подтверждает факт наличия в системе функционала, выполняющего заявленные требования по безопасности.
Профили
Профиль защиты - одно из основных понятий "Общих критериев". В тексте стандарта это понятие определяется следующим образом: "Независимая от реализации совокупность требований безопасности для некоторой категории продуктов или ИТ-систем, отвечающая специфическим запросам потребителя".
Можно сказать, что в привычных терминах профиль имеет много общего с техническим заданием. Все очень похоже - то же самое описание функционала будущей системы защиты информации (СЗИ), причем минимально привязанное к конкретной реализации (теоретически никак не привязанное). Вообще говоря, профиль допускается создавать как непосредственно для продукта, который представляет собой СЗИ, так и для защитной подсистемы какого-либо (практически любого) программного продукта. Более того, можно написать один профиль для целой совокупности программных продуктов. Так, существуют профили (на сегодняшний день только в виде проектов) для межсетевых экранов, профиль для СУБД (по сути, набор требований по безопасности для защиты СУБД), для клиентской ОС и т. д.
Каталог ФБО
Все механизмы защиты, описанные в профиле, называются функциями безопасности объекта (ФБО). Автор профиля не выдумывает ФБО, а берет их из специального "каталога" функций безопасности, который входит составной частью в "Общие критерии" (2-я часть ГОСТ). В данном "каталоге" функции безопасности описаны достаточно жестко и формально. В то же время в этих спецификациях приведены формальные и жесткие правила, которые позволяют "модернизировать" функции безопасности, по сути - уточнить и конкретизировать, сделав их адекватными требованиям к конкретному механизму защиты.
В частности, стандарт предусматривает такие операции, как "уточнение" и "выбор". Операция " уточнение " используется для добавления к требованию некоторых подробностей (деталей), а операция " выбор " - для выбора одного или нескольких элементов из перечня в формулировке требования.
Угрозы, политики и предположения безопасности
Но и набор функций безопасности не формируется автором профиля защиты "из головы". Согласно ОК, в профиль защиты включаются только те функции безопасности, которые должны защищать от угроз и соответствовать политике безопасности. Отсутствие всех остальных функций безопасности "объясняется" предположениями безопасности.
Предположения безопасности - это описание конкретных условий, в которых будет эксплуатироваться система. Например, компьютер с установленной программой должен стоять в помещении, находящемся под охраной. В дальнейшем на основе предположений можно, например, отсекать часть угроз как нереализуемых в данных условиях эксплуатации информационной системы. Другой пример предположения - требования к эксплуатации программного продукта, выполняющего шифрование и расшифровывание данных на диске после идентификации и аутентификации пользователя по имени и паролю. Очевидно, что злоумышленник способен получить доступ к данным, если сможет "перехватить" пароль и имя пользователя с помощью программ-закладок. Однако защита от этой угрозы уже выходит за рамки действия простого ПО шифрования данных (это скорее требование к "доверенной операционной системе"). Поэтому для сужения требований функционала к ПО шифрования вводится предположение безопасности, которое формулируется так: "Предполагается, что программная и аппаратная среда функционирования является доверенной". Введя такое предположение, разработчик профиля защиты для ПО шифрования сокращает избыточные функционалы.
Угрозы точно так же выбираются из предопределенного списка и призваны обозначить, от чего именно защищает система защиты информации, соответствующая данному профилю защиты.
Понятие политики безопасности определено в 1-й части ОК следующим образом: "Одно или несколько правил, процедур, практических приемов или руководящих принципов в области безопасности, которыми руководствуется организация в своей деятельности". В общем случае такой набор правил представляет собой некий функционал программного продукта, который необходим для его использования в конкретной организации. Если подходить к политике более формально, то она есть набор неких требований к функционалу системы защиты, закрепленных в ведомственных документах. Например, в финансовых организациях зачастую принято, чтобы в продукте предусматривалось присутствие нескольких административных ролей: администратор, аудитор и оператор системы защиты. Такое ролевое управление информационной безопасностью - скорее дань традиции и теоретически позволяет избежать "сговора" администратора и злоумышленника из числа пользователей. Для того, чтобы включить данный функционал продукта в профиль защиты, целесообразнее всего ввести соответствующую политику безопасности, например, так: "Администраторы должны нести ответственность за свои действия в системе".
Уровень доверия
Кроме функций безопасности, в структуру документа, описывающего профиль защиты, входит раздел "Требования доверия к безопасности". Эти требования, как и функции безопасности, выбираются разработчиком профиля из "каталога" требований доверия, фактически составляющего всю третью часть "Общих критериев". Однако, в отличие от "формального" набора функций, для требований доверия в стандарте сформированы определенные наборы, которые называются "Оценочными уровнями доверия" (ОУД). Самый низкий уровень доверия - 1-й, самый высокий - 7-й.
Если провести аналогию с определениями, уже знакомыми нам по руководящим документам (РД) Гостехкомиссии РФ, то ОУД имеют много общего с уровнями проверки недекларированных возможностей (см. РД Гостехкомиссии России "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларируемых возможностей").
Но по сравнению с РД в ОК значительно больше внимания уделено процедурам поставки (важно, чтобы при выполнении процедуры поставки программный продукт был защищен от подмены или модификации) и поддержке продукции. Программный продукт, который не поддерживается должным образом разработчиком, не может считаться "доверенным", не может претендовать на высокий уровень ОУД, а значит, не может применяться для защиты ценной информации.
Задание по безопасности
Если профиль защиты - это описание функционала продукта, не зависящее от его реализации и имеющее много общего с техническим заданием, то задание по безопасности содержит и список функций безопасности профиля, и описание того, как эти функции безопасности реализованы непосредственно в продукте. Определение задания по безопасности в стандарте таково: "Совокупность требований безопасности и спецификаций, предназначенная для использования в качестве основы для оценки конкретного ОО". Если продолжить аналогию с проектной документацией, то задание по безопасности имеет много общего с техническими условиями на СЗИ.
Качество жизни
При всей своей объемности и, на первый взгляд, сложности новый ГОСТ дает в руки разработчикам дополнительные, доселе недоступные возможности, демонстрируя достаточную гибкость как инструментарий. Если разработчик системы защиты считает, что его продукт пусть не намного, но все же в чем-то превосходит продукт конкурента, то он всегда может создать собственный профиль защиты (который имеет пусть не намного, но больше функций безопасности) и сертифицировать по нему свою продукцию. Кроме того, немаловажно, что гибкость ОК позволяет довольно быстро (по сравнению с разработкой прежних РД Гостехкомиссии) реагировать на появление новых информационных угроз и СЗИ, защищающих от этих угроз.
Такая гибкость имеет и свои недостатки, причем, как обычно, эти недостатки - продолжение ее достоинств. Ясно, что, следуя описанной логике создания профилей защиты, можно в скором времени "наплодить" их огромное количество. Как следствие, появится потребность в экспертах, которые будут хорошо ориентироваться в "Общих критериях", в существующих профилях, смогут разрабатывать профили защиты и задания по безопасности (а такая работа стоит отнюдь не дешево).
Порядок аттестации объектов
Регламентом стандарта предусмотрено, что сначала владелец ИС создает ее профиль защиты или задание по безопасности. Формализовать критерии выбора - что именно писать, профиль или задание по безопасности, довольно трудно. Если организация небольшая, то более эффективной будет разработка задания по безопасности. Если информационная система очень велика - возьмем для примера ведомство с огромным количеством филиалов, причем требования к подсистеме информационной безопасности примерно одинаковы для всех филиалов, но информационные системы в филиалах построены с некоторыми различиями, - то эффективнее разработать профиль защиты. Такой профиль описывает функции безопасности, которые должны обеспечиваться в ИС каждого филиала независимо от того, с помощью каких ОС, СУБД и прикладного ПО они построены. А для каждого филиала в данном случае необходимо написать отдельное задание по безопасности.
После разработки задания в соответствии со списком необходимых функций безопасности подбираются средства или системы защиты информации, реализующие данные функции. Выбранные системы должны быть сертифицированы по ГОСТ 15408 на соответствие разработанным заданиям по безопасности. В подсистеме защиты информации применяются выбранные средства или СЗИ в той конфигурации, в которой они описаны в задании по безопасности на ИС. И, наконец, подсистема информационной безопасности сертифицируется на соответствие заданию безопасности по ГОСТ 15408.
Учитывая все вышесказанное, нетрудно заметить, что для аттестации ИС недостаточно простой установки сертифицированной ОС (например, Windows XP) на всех компьютерах организации. Необходимо разработать профиль (как минимум - задание по безопасности) на автоматизированную систему с непротиворечивой моделью угроз, политик и предположений безопасности. После этого нужно подобрать такие сертифицированные по "Общим критериям" программные продукты, функции безопасности которых позволяют защититься от описанных угроз (и вот в числе этих продуктов уже может использоваться ОС Windows XP).
