В соответствии с требованиями Закона Республики Беларусь от 10.11.2008 № 455-3  «Об информации, информатизации и защиты информации» информация, содержащаяся в государственных информационных системах, должны обрабатываться в информационных системах с применением системы защиты информации, аттестованной в порядке, установленном Советом Министров Республики Беларусь.

 ОБЩИЕ ПОЛОЖЕНИЯ

 Система защиты информации (далее - СЗИ) включает в себя комплекс организационных и технических мер, направленных на обеспечение конфиденциальности, целостности и доступности информации.

При создании систем защиты информации информационных систем должны применяться средства защиты информации, имеющие сертификат соответствия, выданный в Национальной системе подтверждения соответствия Республики Беларусь, или положительное экспертное заключение по результатам государственной экспертизы.

Комплекс мероприятий по созданию системы защиты информации в информационных системах включает:

• классификацию хранящихся и обрабатываемых в информационной системе сведений и разделение информации по категориям доступа;
• анализ организационной структуры информационной системы, порядка организации вычислительных процессов и условий ее функционирования;
• присвоение информационной системе класса типового объекта информатизации в соответствии с требованиями СТБ 34.101.30-2007;
• разработку или корректировку политики информационной безопасности организации;
• разработку или корректировку задания по безопасности на информационную систему в соответствии с требованиями технических нормативных правовых актов в области защиты информации;
• реализацию требований задания по безопасности в информационной системе;
• оценку соответствия системы защиты информации требованиям нормативных правовых актов в области защиты информации, в том числе технических нормативных правовых актов, путем проведения мероприятий по аттестации системы защиты информации;
• ввод информационной системы в эксплуатацию.

Разработка СЗИ может осуществляться только организацией, имеющей специальное разрешение (лицензию) Оперативно – аналитического центра при Президенте Республики Беларусь. В соответствии с Инструкцией о порядке согласования выполнения работ и (или) оказания услуг в государственных органах (организациях) при осуществлении деятельности по технической защите информации, в том числе криптографическими методами, включая применение электронной цифровой подписи, утвержденной Приказом ОАЦ от 16.11.2010 №82, разработка СЗИ осуществляется после согласования с ОАЦ.

РАЗРАБОТКА ЗАДАНИЯ ПО БЕЗОПАСНОСТИ

 Для разработки Задания по безопасности (далее – ЗБ) наличие лицензии на право осуществления деятельности в области защиты информации не требуется. Разработка ЗБ может осуществляться как специалистами заказчика информационной системы (подразделением технической защиты информации), так и сторонними организациями, привлекамыми на договорной основе.

Задание по безопасности разрабатывается в соответствии с требованиями Приложения Б СТБ 34.101.1-2004.

Общая структура ЗБ

Содержание ЗБ

1. Введение в описание задания по безопасности

Введение в описание ЗБ должно включать следующие структурные элементы:

а)       идентификацию ЗБ, которая должна содержать обозначения и описания, необходимые для идентификации ЗБ и объекта, к которому оно относится;

б)      обзор ЗБ, в котором должно быть представлено краткое описание разделов ЗБ. Обзор должен быть достаточно подробным, чтобы потенциальный потребитель объекта мог составить заключение о
пригодности объекта для своих целей. Обзор должен быть также удобным для представления в виде отдельного реферата в перечне сертифицированных продуктов;

в)       требования соответствия стандарту, в которых должна быть определена степень достоверности, с которой ЗБ соответствует функциональным, гарантийным требованиям или непосредственно ПЗ
типового объекта.

2.    Описание объекта

Как правило, автоматизированные системы обладают следующими свойствами:

находятся под контролем одного владельца;

строятся для достижения определенных целей и для функционирования в определенном режиме;

подвержены частым изменениям, как в плане технического устройства, так и в плане эксплуатационных требований;

состоят из значительного, порой очень большого числа компонентов;

содержат покупные компоненты с большим числом возможных вариантов конфигурирования;

оставляют за владельцем выбор баланса между техническими и нетехническими мерами безопасности;

содержат компоненты с различными уровнями и типами доверия к безопасности.

В раздел «Описание ОО» включается общая информация об ОО, предназначенная для пояснения требований безопасности, предъявляемых к ОО.

В разделе должно быть четко определено что представляет собой ОО: это система или отдельный продукт ИТ (модуль, компонент).

Описание объекта должно обеспечивать понимание требований его безопасности и давать пред­ставление о типе продукта или системы ИТ, а также содержать описание как физических (аппаратных и/или программных компонентов/модулей), так и логических (характеристик ИТ и безопасности объекта) возможностей и областей применения объекта. Описание границ ОИТ, которое должно включать описание как физических (аппаратных и/или программных компонентов/модулей), так и логических (характеристик ИТ и безопасности объекта) возможностей объекта

Описание объекта представляет данные для его оценки. Информацию, содержащуюся в описании объекта, можно использовать в процессе оценки для выявления несоответствий между политикой, задачами и требованиями безопасности объекта. Если объект представляет продукт или систему, основной функцией которых является безопасность, то этот раздел можно использовать для описания более широкого круга области применения объекта.

Описание «основных функциональных возможностей ОО» включает в себя описание функциональных возможностей ОО, а не только характеристик безопасности (в случае, если обеспечение безопасности не является единственным предназначением ОО). Вкратце в этом подразделе также можно описать принцип работы ОО.

Описание «границ ОО» - это описание того, что включает и чего не включает в себя ОО.

Объектом оценки, как правило является ОИТ, доступ ко всем ресурсам которого для всех сотрудников и пользователей открывать нет необходимости. Поэтому в описании ОО должны быть оговорены моменты для кого предоставляется доступ, к каким ресурсам и т.д. Желтельно, при написании этого подраздела иметь в виду какие планируются роли пользователей ОО и какими правами они пользуются.

Как правило, автоматизированные системы взаимодействуют с другими системами и зависят от них. Поэтому в описание ОО должен быть включен подраздел, описывающий взаимодействие ОО с другими системами. Как это взаимодействие осуществляется, какие специальные средства предоставления доступа должны применяться (например, специальная система предоставления доступа к АСУ Экспресс для Системы продажи билетов)

Оцениваемая автоматизированная система может взаимодействовать с другими АС и/или входить в состав более крупной системы. Объект оценки (ОО) включает в себя как технические средства, так и их эксплуатационную среду. Его граница пролегает там, где кончается непосредственный контроль системы. Все остальное рассматривается как среда функционирования ОО.

У автоматизированной системы есть множество предоставляемых ею функций, внешние интерфейсы, а также внутренняя структура и внутренние интерфейсы. Каждый компонент может предоставлять одну или несколько функций и быть реализованным в виде одного или нескольких продуктов ИТ.

 3.    Среда безопасности ОО

В раздел «Среда безопасности ОО» включается описание аспектов среды безопасности, в которой предполагается использование ОО, а также способ использования ОО.

Раздел «Среда безопасности ОО» содержит описание:

а) предположений о предназначении ОО и о его среде эксплуатации, а также безопасного функционирования ОО;

б) угроз безопасному функционированию ОО;

в) ПБО, которой должен удовлетворять ОО.

Описание среды безопасности объекта должно содержать связанные с безопасностью характери­стики среды, в которой будет использоваться объект, и предполагаемый способ эксплуатации объекта. Оно включает:

а) предположения, которые должны содержать следующие связанные с безопасностью характе­ристики среды объекта:

-         информацию о предполагаемом порядке использования объекта, в том числе о прикладной области применения, предполагаемой стоимости активов и о возможных ограничениях на использование;

-         информацию о среде, в которой будет использоваться объект, включая вопросы, связанные с КСБО, подбором персонала и внешними связями с другими объектами;

В ЗБ целесообразно включать следующие группы предположений:

-         предположения относительно предопределенного использования ОО;

-         предположения, связанные с защитой любой части ОО со стороны среды (например, физическая защита);

-         предположения связности (например, межсетевой экран должен быть единственным сетевым соединением между частной (защищаемой) и внешней (потенциально враждебной) сетью);

-         предположения, имеющие отношение к персоналу (например, предполагаемые пользовательские роли, основные обязанности (ответственность) пользователей и степень доверия этим пользователям).

Необходимо помнить, что все идентифицированные предположения безопасности должны быть учтены при формировании целей безопасности. Т.е. предположения безопасности, которые по какой-либо причине не могут быть учтены при формировании целей безопасности, целесообразно включать в ЗБ в качестве сопроводительной информации.

Чаще всего невозможно полностью идентифицировать все предположения с первого раза. Поэтому предположения могут быть дополнительно идентифицированы на протяжении всего периода разработки ЗБ. В частности, при формировании раздела ЗБ «Обоснование» (например, при демонстрации пригодности целей безопасности для противостояния идентифицированным угрозам) необходимо установить, были ли сделаны предположения, не нашедшие своего отображения в ЗБ.

Наряду с использованием итерационного подхода к идентификации предположений безопасности, необходимо избегать включения в раздел «Среда безопасности ОО» любых «предположений», связанных с эффективным использованием конкретных функций безопасности ОО (ФТБ), которые идентифицированы в процессе формирования раздела «Обоснование». Соответствующую этим «предположениям» информацию целесообразно включать в ЗБ в виде требований безопасности для не-ИТ-среды.

Однако в раздел «Среда безопасности ОО» целесообразно включать предположения, имеющие отношение к персоналу, например, следующего вида: «для ОО определены один или несколько администраторов, в обязанности которых входит обеспечение надлежащей настройки и соответствующего использования ФТБ».

б) угрозы активам, которые исходят из окружающей среды объекта и создают опасность для его работы и против которых требуется защита средствами объекта или его среды.

Угрозы должны быть описаны в понятиях: источник угроз (нарушитель), атака и актив, который подвергается атакам; источники угроз – в понятиях: квалификация, используемый ресурс и мотивация; атаки – в понятиях: методы атак, используемые уязвимые места и возможности для атаки.СТБ 34.101.1-2004

Если задачи безопасности объекта выводятся только из политики безопасности организации и предположений, то структурный элемент «Угрозы» в ЗБ можно опустить;

в) политику безопасности организации, которая должна определять и при необходимости объ­яснять разделы политики безопасности или правила, которым должен соответствовать объект. Каждый раздел политики следует представлять в форме, позволяющей использовать ее для формулирования четких задач безопасности ИТ.

Если задачи безопасности объекта выводятся только из угроз и предположений, то структурный элемент «Политика безопасности организации» в ЗБ можно опустить.

Для территориально разнесенного объекта анализ среды безопасности объекта (предположений, угроз, политики безопасности) должен производиться отдельно для каждого района расположения объекта и условий его эксплуатации.

 4.    Задачи безопасности

Задачи безопасности должны отражать намерение противостоять всем установленным угрозам и/или поддерживать принятую политику безопасности и предположения. Различают следующие типы задач безопасности:

а) задачи безопасности для объекта, которые должны быть четко сформулированы для того, чтобы их решение позволило противостоять угрозам средствами безопасности объекта и/или поддержи­вать политику безопасности организации, которой должен следовать объект;

б) задачи безопасности для среды, которые должны быть четко сформулированы для того, чтобы их решение позволило противостоять угрозам средствами безопасности объекта и среды и/или поддерживать политику безопасности организации, которой должен следовать объект. Формулировки задач безопасности для среды могут повторять (частично или полностью) предположения в описании среды безопасности объекта.

Примечание - Если противодействие угрозе или проведение политики безопасности возлагается на объект и его среду, то соответствующие задачи безопасности формулируются для объекта и среды.

 5.    Требования безопасности информационных технологий

Требования безопасности ИТ должны задаваться следующим образом:

а) в разделе «Требования безопасности объекта» должны быть представлены функциональные и гарантийные требования безопасности, которым должен отвечать объект, и заключение о соответ­ствии требований задачам безопасности объекта.

Требования безопасности объекта включают в себя:

1) функциональные требования безопасности объекта, которые должны задаваться как функциональные компоненты по СТБ 34.101.2.

В тех случаях, когда по условиям безопасности требуется выделить различные аспекты одного и того же требования (например, при идентификации нескольких типов пользователей), можно повторно (т. е. применив операцию итерации) использовать один и тот же компонент.

Если гарантийные требования объекта включают компонент AVA_SOF.1 «Оценка стойкости средства обеспечения безопасности», то в описании функциональных требований безопасности объекта должен устанавливаться минимальный уровень стойкости для СБ, реализованных вероятно­стными методами или методами перестановок (например, с помощью паролей или хэш-функций). КСБО должен обладать, по крайней мере, этим уровнем стойкости. Имеется три уровня стойкости СБ: базовый, средний и высокий. Выбор уровня стойкости производится в соответствии с задачами безо­пасности объекта. При решении определенных задач безопасности допускается для реализации некоторых функциональных требований выбирать специальную меру стойкости СБ.

При выборе уровня стойкости СБ (компонент AVA_SOF.1 «Оценка стойкости средства обеспечения безопасности» необходимо установить, соответствуют ли выбранные уровни стойкости отдельных СБ и объекта в целом общему минимальному уровню стойкости;

2) гарантийные требования безопасности объекта, которые должны задаваться в виде одного из УГО, возможно, усиленного за счет гарантийных компонентов по СТБ 34.101.3. Усиление УГО в ЗБ может осуществляться также за счет включения дополнительных гарантийных компонентов, не входящих в СТБ 34.101.3;

б) в разделе «Требования безопасности для среды ИТ» должны содержаться требования безопасности, которым должна соответствовать среда ИТ объекта. Если объект независим от среды ИТ, то этот раздел можно опустить. Требования безопасности, не относящиеся к среде ИТ, но часто используемые на практике, могут не включаться в ЗБ, так как они не связаны непосредст­венно с реализацией объекта;

в) перечисленные ниже условия формирования требований безопасности в равной степени отно­сятся как к функциональным и гарантийным требованиям безопасности объекта, так и к его среде:

1) требования безопасности ИТ должны быть представлены в виде компонентов требований безопасности по СТБ 34.101.2 и СТБ 34.101.3. Если компоненты требований безопасности по СТБ 34.101.2 и СТБ 34.101.3 не применимы для ЗБ объекта или этих компонентов недостаточно, то недостающие требования безопасности задаются независимо от компонентов требований по СТБ 34.101.2 и СТБ 34.101.3;

2) дополнительные функциональные и гарантийные требования безопасности должны быть четко и однозначно сформулированы, чтобы не возникало трудностей при их оценке и при проверке степени их реализации. Образцом уровня детализации и способа представления требований безопасности может стать представление функциональных или гарантийных требований по СТБ 34.101.2 и СТБ 34.101.3;

3) должны быть использованы все необходимые операции для конкретизации требований безо­пасности с тем, чтобы обеспечить соответствие требований задачам безопасности. Все разрешенные операции над компонентами требований должны быть завершены.

4) должны быть удовлетворены все зависимости между требованиями безопасности объекта. Указанные зависимости могут быть удовлетворены за счет включения необходимых требований в перечень требований безопасности объекта либо среды.

 6.    Общая спецификация объекта

Структурный элемент «Общая спецификация объекта» должен содержать описание КСБО и мер гарантии ОО, отвечающих требованиям безопасности. В ряде случаев функциональная информация, являющаяся частью общей спецификации объекта, идентична информации, содержащейся в требо­ваниях семейства ADV_FSP «Функциональная спецификация».

Общая спецификация объекта включает:

а) описание комплекса средств безопасности объекта, которое должно включать перечень СБ ИТ и определять, каким образом эти средства реализуют функциональные требования безопасности объекта. В описании должно быть взаимное соответствие СБ и требований с четким указанием, какие средства соответствуют каким требованиям, а также подтверждение того, что все требования удов­летворены.

Каждое СБ должно обеспечивать реализацию, по крайней мере, одного функционального требо­вания безопасности объекта. Это достигается тем, что:

1) СБ ИТ определяются неформальным способом на уровне описания, необходимом для пони­мания их назначения;

2) механизмы безопасности должны соответствовать СБ с тем, чтобы можно было определить, какие механизмы безопасности используются для реализации каждого средства;

3) если в состав гарантийных требований безопасности объекта входит компонент AVA_SOF.1 «Оценка стойкости средства обеспечения безопасности», то должны быть указаны СБ ИТ, реализо­ванные с помощью вероятностных методов или метода перестановок (например, с помощью пароля или хэш-функции). Возможность нарушения механизма безопасности таких средств посредством предна­меренного или случайного воздействия имеет непосредственное отношение к безопасности объекта. Необходимо провести анализ стойкости этих средств. Стойкость каждого средства должна быть оценена как базовая, средняя или высокая или как введенная дополнительно мера стойкости. Результаты оценки стойкости используются экспертом для проверки адекватности и корректности реализации требуемого уровня стойкости;

б) описание мер гарантии, обеспечиваемые установленными гарантийными требованиями. Меры гарантии должны быть отражены таким образом, чтобы было понятно, какие меры участвуют в реали­зации требований.

Меры гарантии могут быть отражены в ЗБ также путем ссылки на соответствующие планы обес­печения качества, жизненного цикла или управления.

 7.    Требования соответствия профилю защиты

В ЗБ может содержаться требование обеспечения соответствия объекта требованиям безопас­ности одного или нескольких ПЗ. Эта дополнительная часть ЗБ включает разъяснения, подтверж­дения и иные вспомогательные материалы. Требование соответствия объекта ПЗ может повлиять на форму описания и содержание той части ЗБ, в которой приведены задачи и требования безопасности объекта. Это влияние может быть сведено к следующим случаям:

а) при отсутствии в ЗБ требований на соответствие ПЗ задачи и требования безопасности объекта представляются так, как приведено в Б.2.5 и Б.2.6 (при этом требования, приведенные в ПЗ, не включаются в ЗБ);

б) при наличии в ЗБ только требований соответствия требованиям безопасности, приведенным в ПЗ, то достаточно ссылки на ПЗ, чтобы определить и оценить задачи и требования безопасности объекта (при этом не требуется приводить повторно описание ПЗ);

в) если в ЗБ есть требование не только обеспечить соответствие ПЗ, но и провести более глубокую детализацию требований, приведенных в ПЗ, то в ЗБ должно быть показано, что требование детали­зацииудовлетворено.

Такая ситуация обычно возникает, когда ПЗ содержит незавершенные операции. В этом случае в ЗБ может быть сделана ссылка на ПЗ, но дополнительные детализированные требования приводятся в ЗБ. При определенных обстоятельствах, когда дополнительные детализированные требования являются существенными и их реализация обязательна, то необходимо в ЗБ повторно привести описание требований, приведенных в ПЗ;

г) если в ЗБ есть требование не только обеспечить соответствие ПЗ, но и расширить перечень задач и требований безопасности, то в разделах ЗБ, где имеются ссылки на ПЗ, должны быть приве­дены дополнительные задачи и требования безопасности. Если дополнительные задачи и требо­вания безопасности являются существенными, то необходимо в ЗБ повторно привести описание задач и требований безопасности, приведенных в ПЗ.

В настоящем стандарте не рассматриваются случаи, когда в ЗБ требуется лишь частичное его соответствие ПЗ.

В стандарте не устанавливается никаких правил описания в ЗБ задач и требований безопас­ности, приведенных в ПЗ, или ссылок на них. Основополагающим является требование, чтобы содер­жание ЗБ было полным, ясным, исключало различные толкования, позволяло провести оценку ЗБ, являлось бы приемлемой основой для оценки объекта и допускало сравнение с любым нужным ПЗ.

Если имеется требование соответствия ЗБ нескольким ПЗ, то соответствующий раздел ЗБ должен для каждого ПЗ включать следующие данные:

а) ссылку на профиль защиты, на основе которой определяется тот ПЗ, которому должно соот­ветствовать ЗБ, вместе со всеми дополнительными материалами, которые могут усилить условие соответствия. Правильно сформулированное условие соответствия (после усиления) подразумевает, что объект отвечает всем требованиям ПЗ;

б) уточнение профиля защиты, определяющее формулировки задач и требований безопасно­сти объекта, которые удовлетворяют допустимым операциям ПЗ или проводят дальнейшую детали­зацию задач и требований безопасности, т. е. уточняют требования безопасности;

в) дополнение профиля защиты, определяющее формулировки задач и требований безопас­ности объекта, которые дополняют задачи и требования безопасности, приведенные в ПЗ.

8.    Обоснование задания по бзопасности

Обоснование ЗБ должно подтвердить, что:

а) ЗБ содержит полную и взаимоувязанную совокупность требований безопасности;

б) разработанный в соответствии с заданными требованиями объект будет обладать эффективным набором средств обеспечения безопасности ИТ в среде безопасности;

в) общая спецификация объекта отражает заданные требования.

Обоснование также должно подтвердить соответствие ЗБ каждому ПЗ, указанному в ЗБ. В обоснование должны входить:

а) обоснование задач безопасности, которое подтверждает, что сформулированные задачи безопасности охватывают все указанные аспекты среды безопасности объекта и верно отражают их;

б) обоснование требований безопасности, которое подтверждает, что заданная совокупность требований безопасности объекта и его среды отвечает задачам безопасности.

При обосновании требований безопасности необходимо показать, что:

1) совокупность компонентов функциональных и гарантийных требований объекта и его среды обеспечивает выполнение установленных задач безопасности объекта;

2) набор требований безопасности образует единую и взаимоувязанную совокупность требований;

3) выбор требований безопасности обоснован.

Специальное обоснование необходимо при задании требований, не содержащихся в СТБ 34.101.2 и СТБ 34.101.3, а также в случае неудовлетворенных зависимостей;

4) выбор уровня стойкости СБ в ПЗ обоснован.

Требования к стойкости СБ должны быть согласованы с задачами безопасности объекта;

в) обоснование общей спецификации объекта, которое должно показывать, что СБ и гаран­тийные меры отвечают требованиям безопасности объекта.

При обосновании общей спецификации объекта необходимо показать, что:

1) СБ реализуют функциональные требования безопасности объекта;

2) требования к стойкости СБ обоснованы либо такие требования не предъявляются;

3) подтверждено условие соответствия принятых мер гарантии гарантийным требованиям. Уровень детализации обоснования общей спецификации должен соответствовать уровню дета­лизации описания КСБО.

г) обоснование требования соответствия профилям защиты, которое содержит объяснения различий между задачами и требованиями безопасности, представленными в ЗБ и в каждом ПЗ, соответствие которым должно быть обеспечено. Если в ЗБ отсутствует требование соответствия ПЗ или задачи и требования безопасности, представленные в ЗБ и в ПЗ, совпадают, то этот раздел в ЗБ можно опустить.

Обоснование должно предоставляться по желанию потребителей ЗБ.

АТТЕСТАЦИЯ СИСТЕМ ЗАЩИТЫ ИНФОРМАЦИИ

Аттестация СЗИ проводится в соответствии с Положением о порядке проведения аттестации СЗИ, утвержденным постановлением Советов Министов Республики Беларусь от 26.05.2009 № 675.

Аттестацию систем защиты информации проводят организации, имеющие соответствующее специальное разрешение (лицензию) Оперативно-аналитического центра при Президенте Республики Беларусь (далее - специализированные организации).

Владельцы государственных информационных систем, имеющие в своем составе подразделения по технической защите информации (далее - владельцы государственных информационных систем), вправе проводить аттестацию систем защиты информации, используемых при обработке информации, содержащейся в государственных информационных системах, владельцами которых они являются.

Аттестация системы защиты информации проводится до ввода информационной системы в эксплуатацию. Основанием для эксплуатации информационной системы является  наличие аттестата соответствия требованиям по защите информации.

Аттестация предусматривает комплексную оценку системы защиты информации в реальных условиях эксплуатации информационной системы (в связя с тем, что аттестация проводится до ввода системы в эксплуатацию, допускается ввод ОО в опытную эксплуатацию)  и включает проведение следующих мероприятий:

анализ исходных данных по аттестуемой системе защиты информации;

разработка программы аттестации;

предварительное ознакомление с информационной системой и системой защиты информации;

проведение обследования информационной системы и системы защиты информации;

анализ разработанной документации по защите информации в информационной системе на соответствие требованиям нормативных правовых актов в области защиты информации, в том числе технических нормативных правовых актов;

проведение испытаний средств защиты информации и оценка системы защиты информации в реальных условиях эксплуатации информационной системы;

анализ результатов испытаний средств защиты информации, системы защиты информации и принятие решения о выдаче аттестата соответствия;

выдача аттестата соответствия.

Аттестация проводится на основании заявки, подаваемой заявителем в специализированную организацию по форме согласно приложению 1, и исходных данных согласно приложению 2 Положения.

В случае проведения аттестации владельцем государственной информационной системы (при наличии в организации подразделения технической защиты информации), заявка на проведение аттестации не оформляется. В этом случае работы по аттестации проводятся аттестационной комиссией, назначенной приказом руководителя организации – владельца государственной информационной системы.

В общем случае процедура аттестации включает в себя следующие мероприятия:

В связи с тем, что аттестация систем защиты информации информационных систем БЖД проводится, как правило, ЦЗИ, т.е. фактически владельцем государственной информационной системы, заявка и договор в этом случае не оформляются. Все остальные процедуры выполнятся в полном объеме.

Аттестация проводится до полного завершения всех проверок вне зависимости от промежуточных результатов испытаний. Если выявленные недостатки невозможно устранить в течение периода проведения аттестации, принимается решение об отказе в выдаче аттестата соответствия.

Сведения об аттестованных системах защиты информации представляются специализированной организацией (владельцем государственной информационной системы) в Оперативно-аналитический центр при Президенте Республики Беларусь не позднее 30 дней со дня выдачи аттестата соответствия.

Аттестат соответствия выдается на период, в течение которого должны обеспечиваться неизменность условий функционирования информационной системы и технологии обработки защищаемой информации, но не более чем на 5 лет.

Владелец аттестованной системы защиты информации несет ответственность за функционирование системы защиты информации в соответствии с законодательством.

В случае изменения условий и технологии обработки защищаемой информации владельцы аттестованных систем защиты информации обязаны пройти повторную аттестацию системы защиты информации.

 ИСХОДНЫЕ ДАННЫЕ, ПРЕДОСТАВЛЯЕМЫЕ ДЛЯ АТТЕСТАЦИИ.

Согласно приложения 2 к Положению о порядке аттестации СЗИ в качестве исходных данных представляются следующие документы:

1. Полное и точное наименование информационной системы, ее назначение.

2. Перечень информации, распространение и (или) предоставление которой ограничено.

3. Организационная структура информационной системы.

4. Правила разграничения доступа в информационной системе.

5. Модель нарушителя правил разграничения доступа в информационной системе.

6. Состав комплекса технических средств, на которых обрабатывается защищаемая информация.

7. Структура используемого программного обеспечения, предназначенного для обработки защищаемой информации, используемые протоколы обмена информацией.

8. Общая функциональная схема информационной системы, включая схему информационных потоков и режимы обработки защищаемой информации.

9. Наличие и характер взаимодействия с другими объектами.

10. Состав и структура системы защиты информации.

11. Сведения о разработчиках системы защиты информации.

12. Наличие сертификатов соответствия либо экспертных заключений на средства защиты информации.

13. Наличие и основные характеристики средств физической защиты информационной системы (помещений, где обрабатывается защищаемая информация и хранятся информационные носители).

14. Документы, устанавливающие отнесение информационной системы к классу типовых объектов информатизации согласно СТБ 34.101.30-2007.

15. Задание по безопасности на информационную систему.

16. Проектная и эксплуатационная документация на систему защиты информации, другие данные, влияющие на обеспечение защиты информации.

17.Организационно-распорядительные документы, регламентирующие вопросы обеспечения защиты информации в информационной системе (выписки из документов), включая:

документ, подтверждающий наличие в организации подразделения по технической защите информации или специально назначенного должностного лица, ответственного за осуществление мероприятий по технической защите информации;

инструкцию по обеспечению защиты информации в информационной системе;

инструкцию о порядке применения средств защиты информации в информационной системе.

18. Программа проведения приемочных испытаний системы защиты информации.

19. Акт и протоколы приемочных испытаний системы защиты информации.

20. Протоколы испытаний средств защиты информации.

21. Протокол оценки задания по безопасности.

Порядок подготовки исходных данных для аттестации СЗИ информационных систем БЖД описан в Инструкции о порядке подготовки исходных данных к аттестации систем защиты информации, утвержденной приказом главного инженера Белорусской железной дороги от 11.11.2010 №1116НЗ.

Содержание предоставляемых документов.

1. Полное и точное наименование информационной системы, ее назначение.

2. Перечень информации, распространение и (или) предоставление которой ограничено.

Если в ИС циркулирует информация, распространение и предоставление которой ограничено (в т.ч. и информация, отнесенная в установленном порядке к гос. секретам), должен быть представлен ее перечень (например, персональные даные гражданина и данные о его личной жизни, информация, составляющая коммерческую и профессиональную тайну и т.д.).

Если такая информация в ИС не обрабатывается, то необходимо документальное подтверждение этого.

Рекомендация: представить перечень информации, которая обрабатывается в ИС.

3. Организационная структура информационной системы.

Здесь должено быть указано: каким образом организовано информационное наполнение системы. Т.е. как организационно проходит информация.

Например: для того, чтобы внести информацию на сайт БЖД необходимо пройти ряд процедур (перечислить эти процедуры).

Здесь же должны быть указаны зоны ответственности должностных лиц и(или) подраздений за целостность той или иной информации, находящейся в ИС.

Необходимо помнить, что организационная структура информационной системы – это не организационно–штатная структура организации (подразделения), эксплуатирующей или обслуживающей ИС!!!

 4. Правила разграничения доступа в информационной системе.

Какие должностные лица (пользователи) и с какими правами имеют доступ к ресурсам (активам) ИС.

5. Модель нарушителя правил разграничения доступа в информационной системе.

В данном документе указывается каким потенциальным нарушителем какой ущерб может быть нанесен и какими средствами, какова величина риска. (пример).

Разрабатывается в основном ЦЗИ совместно с разработчиком. Но может разрабатываться и собственником, разработчиком и.т.д. с обязательным согласованием с ЦЗИ.

6. Состав комплекса технических средств, на которых обрабатывается защищаемая информация.

В данном документе должны быть перечислены реальные технические  средства, на которых обрабатывается защищаемая информация, с описанием их: ЭВМ, сервера и т.д. Вплоть до того, что можно указать даже инвентарные или заводские номера оборудования.

7. Структура используемого программного обеспечения, предназначенного для обработки защищаемой информации, используемые протоколы обмена информацией.

Больше касается разработчика системы. Указать какой используется язык программирования, какие технологии использовались (портлетная технология в Системе продажи проездных документов через Интернет). Может быть представлен алгоритм.

8. Общая функциональная схема информационной системы, включая схему информационных потоков и режимы обработки защищаемой информации.

В данном документе схематично необходимо отобразить все, что так или иначе входит в состав объекта оценки (границы ОО). Необходимо также уточнить по каким протоколам осуществляется передача информации внутри ИС и с субъектами, не входящими в состав ОО, но непосредственно влияющими на работу ИС.

9. Наличие и характер взаимодействия с другими объектами.

Как правило, автоматизированные системы взаимодействуют с другими системами и зависят от них.

В этом документе так или иначе (лучше в виде схемы и ее описания) указать каким образом и с какими ИС осуществляется это взаимодействие.

10. Состав и структура системы защиты информации.

Необходимо отметить, что система защиты информации – это  совокупность органов и (или) исполнителей, используемой ими техники защиты информации, а также объектов защиты, функционирующих по правилам, установленным соответствующими нормативными правовыми актами в области защиты информации, в том числе техническими нормативными правовыми актами.

Т.о. система защиты информации включает в себы не только те средства защиты информации, которые реализованы в ОО, но и средства защиты среды функционирования ОО (средства защиты ОС, сервера, межсетевыые экраны, технические средства резервирования электропитания, средства резервного копирования, физические средства защиты (помещения, ТКШ) и т.д.). Кроме собственно технических и программных средств защиты информации, штат должен быть укомплектован сотрудниками, знающими нормы и правила ИБ организации и понимающими необходимость их соблюдения.

11. Сведения о разработчиках системы защиты информации.

Представляется информация о разработчике информационной системы, если разработка СЗИ не была выделена в отдельный проект.

Разработка СЗИ может осуществляться лишь организацией, имеющей лицензию ОАЦ на выполнение данного вида работ. Поэтому вместе с реквизитами организации разработчика должна быть представлена  копия лицензии.

12. Наличие сертификатов соответствия либо экспертных заключений на средства защиты информации.

Для СЗИ государственных информационных систем должны использоваться только те средства защиты (антивирусы, межсетевые экраны, средства предоставления доступа, криптопровайдеры и т.д.), которые имеют сертификат соответствия, выданный в Национальной системе подтверждения соответствия Республики Беларусь, или положительное экспертное заключение по результатам государственной экспертизы.

13. Наличие и основные характеристики средств физической защиты информационной системы (помещений, где обрабатывается защищаемая информация и хранятся информационные носители).

В этом качестве могут быть представлены документы о применении (вводе в эксплуатацию) систем контроля доступа, сигнализации, описание помещений, в которых эксплуатируется комплекс технических средств, на котором обрабатывается защищаемая информация, шкафов, в которых размещено оборудование и т.д.

14. Документы, устанавливающие отнесение информационной системы к классу типовых объектов информатизации согласно СТБ 34.101.30-2007.

Представляется протокол, которым обосновывается отнесение ИС к класс типовых объектов информатизации. ОИ классифицируются по двум типам: по виду ограничений по распространению информации и по техническим способам обработки защищаемой информации.

15. Задание по безопасности на информационную систему.

Содержание было рассмотрено выше.

16. Проектная и эксплуатационная документация на систему защиты информации, другие данные, влияющие на обеспечение защиты информации.

В качестве проектной документации может представляются техническое задание и (илитехнический проект, а также другая документация, на основании которой производилась разработка. В качестве эксплуатационной документации предоставляется документация, поставляемая с ИС. В руководствах администраторов, пользователей, а также в другой документации должны быть в обязательном порядке отражены требования согласно СТБ 34.101.3 (ГТБ).

17.Организационно-распорядительные документы, регламентирующие вопросы обеспечения защиты информации в информационной системе (выписки из документов), включая:

документ, подтверждающий наличие в организации подразделения по технической защите информации или специально назначенного должностного лица, ответственного за осуществление мероприятий по технической защите информации;

Для аттестации СЗИ ИС БЖД представляется положение о ЦЗИ, который ялвяется ПТЗИ БЖД.

инструкцию по обеспечению защиты информации в информационной системе;

В данной инструкции должны быть отражены все вопросы обеспечения защиты информации в ИС (обязанности обслуживающего персонала, других должностных лиц так или иначе связанных с эксплуатацией и обслуживанием ИС), должны быть рассмотрены вопросы использования э/почты, сети Интернет и т.д.

инструкцию о порядке применения средств защиты информации в информационной системе.

Регламентируется применение технических (программных) средств защиты информации (например, периодичность проверки антивирусами, периодичность обновления баз, порядок использования межсетевых экранов и т.д.)

 18. Программа проведения приемочных испытаний системы защиты информации.

Если СЗИ разрабатывалась отдельно, то эти документы должны быть именно на СЗИ.

Если отдельного задания на разработку СЗИ не было, то предоставляются программа, методика протоколы и т.д. приемки ИС, в которых отражены вопросы проверки выполнения требований по защите информации.

19. Акт и протоколы приемочных испытаний системы защиты информации.

20. Протоколы испытаний средств защиты информации.

21. Протокол оценки задания по безопасности.

Согласно пункту 12 Положение о порядке защиты информации в государственных информационных системах, а также информационных системах, содержащих информацию, распространение и (или) предоставление которой ограничено, любое разработанное ЗБ должно быть оценено аккредитованной ИЛ по требованиям безопасности информации. Протокол должен быть с каждым ЗБ.