Задания по безопасности - Форум по вопросам информационной безопасности

Здравствуйте.
Нужно мне сделать доклад на тему использования Общих критериев в России - применительно к СУБД.
ГОСТы соответствующие я нашел (ГОСТ Р ИСО/МЭК 15408-1-2008) и иже с ним. Раскопал на сайте ФСТЭК профиль защиты (http://www.fstec.ru/_licen/07.doc). Нашлось и задание по безопасности для MS SQL Server (http://www.altx-soft.ru/files/groups/55.pdf).
------------
Дальше я впал в некоторый ступор: больше никаких ЗБ мне найти не удалось. Мне это кажется странным - неужели кроме Microsoft этим никто не занимался? Если нет, то почему? Да и профиль защиты с 2002 года изменений не претерпел...
-------------
И ещё одно: это что - официальный форум ФСТЭК, полуофициальный или просто сообщество знатоков в области лицензий?)

> И ещё одно: это что - официальный форум ФСТЭК, полуофициальный или просто сообщество знатоков в области лицензий?)

Что-то между вторым и третьим.

Саша,
посмотрите реестр сертифицированных СЗИ на сайте ФСТЭК.
Не то что бы много сертифицированных СЗИ по ОК, но вам для доклада хватит :)

Саша,
года 3 назад в этом журнале была статья - интервью с Егоркиным Игорем Васильевичем. Там была затронута эта тема.
Кроме того, на сегодня этой темой активно занимаются Эшелон и ЦБИ. Загляните на их сайты.

1. ЗБ и ТУ обычно не публикуют. Это противоречит основной идее сертификации на соответствие ЗБ/ТУ, но такова российская практика.

2. Сравните список сертифицированных по CC продуктов на сайте commoncriteriaportal.org со списком продуктов, сертифицированых на соответствие ЗБ, в реестре ФСТЭК. Если найдете совпадения - почти наверняка в качестве ЗБ испольховался перевод аналогичного документа с сайта commoncriteriaportal.org (с понижением EAL с исходного 4 до привычного нам 1+).

3. Профили защиты должны были заменить собой РД Гостехкомиссии ввиду их непригодности для сертификации программного обеспечения. Этот процесс застопорился, поэтому идея так и не была реализована. Ни один профиль так и не был утвержден. Сейчас начинается процесс коренной переделки всей системы методических документов ФСТЭК, он займет несколько лет. По утверждению сотрудников ФСТЭК, в итоге останется только сертификация по ГОСТ 15408.

4. Обязательно почитайте ГОСТ 18045, без него вы мало что поймете в ГОСТ 15408.

2Саша - 26163 - ЦИТ.
это что - официальный форум ФСТЭК, полуофициальный или просто сообщество знатоков в области лицензий?
Вообще все видя ПРЕСЛОВУТУЮ ссылку на сайте ФСТЭК сначала считают что это все имеет отношение ко ФСТЭК -
ЭТО ГЛУБОКОЕ ЗАБЛУЖДЕНИЕ!!!
Не раз об этом спрашивал у разных фунциклёров ФСТЭК - рекация - выпученные глаза -
КАКАЯ ССЫЛКА??
а потом - ПУСТЬ БУДЕТ!
В доТАБУРЕТОЧНУЮ эпоху пару персон оттуда даже писали здесь комменты - но УВЫ!!
Форум принадлежит издательству ГРОТЭК или я что-то не так понимаю?
Но вообще не любят ФУНЦИКЛЁРЫ делиться своими сведениями.
Их вполне устраивает формула - ИНФОРМИРОВАННЫЙ ИСТОЧНИК.
Вот только давно уже не источник а болото.
Возьмем за пример г. Тачкова из 8 центра -
Здесь письменно обещал горы и пригорки и берега из киселя ...и все ушло в пар ...некогда мол.
Вообще все это прискорбно и не делает им фавора хотя они и требуют для себя ПИЕТЕТА и всеобщего преклонения (опять сошлусь на написанное здесь очень раньше г. Тачковым - А ПОЧЕМУ МЕНЯ ЗДЕСЬ НЕ Уважают?) . Возникает вопрос - А за что...Собственно?
БЫДЛО _ ПАДИ!

2 Некто: на сайте ЦБИ был, на сайте Эшелона тоже сейчас поискал. Кое-что интересное нашлось, спасибо.)
-------
2 malotavr: спасибо за ответы, я их учту. Ознакомиться с ГОСТ 18045 толком я, правда, уже не успею - завтра надо отвечать. Я ж студент)
-------
Если нетрудно - проверьте основные моменты.
Вопросы вот какие:
1) В ГОСТе вроде бы говорится, что оценка и сертификация - это разные вещи. Лично мне такой подход не вполне понятен. Ведь если была проведена оценка, люди выложили деньги, затратили силы - зачем тогда сертификация? Вначале я думал, что она имеет значение для признания оценки за рубежом - но за это вроде бы отвечает соответствующее международное соглашение... Потом возникла мысль, что оценка может применяться в случае, когда сертификация не требуется, и тогда это обходится дешевле - но что-то я сомневаюсь, что это намного дешевле получения того же самого сертификата... Получается, что в схеме "оценка, потом сертификация" оценка просто упрощает работу ФСТЭК (ну или какого-нибудь ещё органа сертификации), не {ух ты, окошко растягивается!} не давая при этом почти никаких бонусов самому заказчику? Или она является обязательным условием для сертификации?
2) Оценку может давать только специализированная лаборатория. А кто будет утверждать список таких лабораторий?
3) ПЗ может выпустить разработчик, чтобы заявить о своих возможностях. Я где-то встречал такой пример, показывающий превосходство ОК перед нашими действующими стандартами: если есть два межсетевых экрана с разными возможностями, то владелец более удобного и мощного МЭ может выпустить свой ПЗ и сертифицировать свой продукт по нему. А в нашем случае просто будут два одинаковых сертификата ФСТЭК. Так вот вопрос: а зачем разработчику ПЗ создавать? Неужели нельзя сразу создать ЗБ, пусть даже основанное на стандартном ПЗ для МЭ?
4) В чем, черт возьми, смысл сертификации? Только в том, что несертифицированные продукты нельзя применять в системах, где законы нашей страны требуют этого?
5) Можно ли оценить ОО, не оценив перед этим ЗБ? Я так понимаю, что да - но если там будет ошибка, то оценщик вправе все материалы вернуть, и заказчик потеряет деньги.
6) Имеет ли какой-то смысл сертификация ПЗ и ЗБ? Если да, то что будут означать эти сертификаты?
-------
Ну и сама система, как я её понял...
Цели -
а) гибкая система оценки;
б) признание оценок за рубежом.
Есть ОО. Это либо продукт IT, либо система. Второе - законченное, первое - промежуточное.
Есть ПЗ. Это - общие требования к классу ОО. ПЗ может выпустить пользователь - чтобы выразить требования - или разработчик - чтобы заявить о своих возможностях.
Есть ЗБ. Это - описание требований к конкретному ОО. ЗБ может выпускать только разработчик - чтобы продемонстрировать особенности ОО и соответствие определенному ЗБ и ОУД - возможно, даже с усилением.
Есть функциональные требования. Они регламентируют возможности, которые могут быть заложены в ОО, и отвечают на вопрос "Что умеет?".
Есть требования доверия. Они регламентируют такие вещи, как разработка, поставка и поддержка ПО и отвечают на вопрос "Почему можно верить?".
Есть структура "класс – семейство – компонент". Есть пакеты, объединяющие компоненты. Эта структура справедлива и для функциональных требований, и для требований доверия. Эти элементы включаются в соответствующие части ПЗ и ЗБ.
Сначала оценивается ПЗ. Потом ЗБ - в соответствии с ПЗ. Потом ОО - в соответствии с ЗБ. Потом можно всё это до полного счастья сертифицировать.
------------
Был бы очень признателен, если Вы глянете хотя бы последнюю часть и уберете оттуда явный бред. Предложения, пожелания, конструктивная и неконструктивная критика всячески приветствуются.
Времени у меня завтра немного - менее получаса - не хотелось бы их потратить совершенно зря для слушателей.)

> 1) В ГОСТе вроде бы говорится, что оценка и сертификация - это разные вещи.

В упор не помню, чтобы в стандарте что-то говорилось про сертификацию, поэтому ответить не могу.

> 2) Оценку может давать только специализированная лаборатория. А кто будет утверждать список таких лабораторий?

Испытательные лаборатории проходят аккредитация в соответствующей системе сертификации (ФСТЭК, Газпромсерт и т.п.)

> 3) ПЗ может выпустить разработчик, чтобы заявить о своих возможностях.

Не так. Продукт оценивается на соответствие ЗБ, которое действительно пишет разработчик (Если помните структуру ЗБ, там есть краткая спецификация ОО, которую кроме разработчика фиг кто напишет). Каждый продукт сертифицируется на свое ЗБ.

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

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

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

> 5) Можно ли оценить ОО, не оценив перед этим ЗБ?

Нет. Оценка ЗБ решает несколько задач.

1. Подтверждает, что заявленных требований безопасности достаточно для противодействия заявленным угрозам/поддержки заявленных требований политики.

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

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

> 6) Имеет ли какой-то смысл сертификация ПЗ и ЗБ? Если да, то что будут означать эти сертификаты?

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

> ... функциональные требования ... регламентируют возможности, которые могут быть заложены в ОО, и отвечают на вопрос "Что умеет?".

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

> требования доверия... отвечают на вопрос "Почему можно верить?".

Скорее "до какой степени заявленные функции были проверены незавиимым оценщиком?". Чем ниже ОУД, тем меньше причин доверять результатам сертификации.

> Сначала оценивается ПЗ. Потом ЗБ - в соответствии с ПЗ. Потом ОО - в соответствии с ЗБ. Потом можно всё это до полного счастья сертифицировать.

ПЗ может не быть совсем (например, в случае со ФСТЭКовской сертификацией - у нас нет утвержденных профилей). Соответствие ЗБ ПЗ оценивается только в том случае, если в ЗБ сделано утверждение о соответствии ПЗ. В противном случае оценивается только корректность ЗБ.

По поводу сертификации...
ГОСТ Р ИСО/МЭК 15408-1-2008 в подразделе 4.2 содержит вот такую фразу: "Для повышения согласованности выводов, полученных при оценке, ее конечные результаты могут быть представлены на сертификацию. Процедура сертификации представляет собой независимую экспертизу результатов оценки, которая завершается их утверждением или выдачей сертификата. Сведения о сертификатах обычно публикуются и являются общедоступными. Сертификация является средством обеспечения большей согласованности в применении критериев безопасности ИТ".
Отсюда получается, что оценка и сертификация есть вроде бы разные вещи. Вот это меня и сбило несколько с толку: если ФСТЭК выдает сертификат, то, наверное, он же и проводит оценку. А если оценку будет проводить не он?
---------------
По поводу ПЗ тоже цитата из ГОСТа, подраздел - ой, даже подподпункт - 5.4.1.4.2:
"Допускается разработка ПЗ сообществами потребителей, разработчиками продуктов ИТ или другими сторонами, заинтересованными в определении такой общей совокупности требований. ПЗ предоставляет потребителям средство ссылки на определенную совокупность потребностей в безопасности и облегчает будущую оценку в соответствии с этими потребностями."
Получается всё-таки, что ПЗ тоже может кто угодно разработать. Проводя аналогию с ТУ: разработать ниочемный ПЗ - и сертифицироваться на соответствие ему тоже можно?
---------------
З. Ы. За разъяснения спасибо.
З. З. Ы. В принципе, большого значения последние вопросы уже не имеют - основную картинку я худо-бедно теперь представляю, кажется. Это уже мелкие детали - скорее всего, до них и не дойдет.
Просто в реальной жизни я, естественно, ни с какими ПЗ и ЗБ не сталкивался, сертификаты не получал и представителя ФСТЭК видел один раз в жизни...) Поэтому вот привести цитат кучку я могу, а вот на реальный мир их спроецировать - уже нет.

В моем понимании (клонит в сон) если иностранное "что либо" должно быть сертифицировано в России и имеет сертификат у себя на родине в Зимбабве
оценка - это подтверждение этого сертификата или решение на пере сертификацию по Русскому обычаю.
Скорее всего этим занимаются аккредитованные ФСТЭК органы по сертификации и испытательные лаборатории!
Может не туда влез простите! (Уснул на столе!!!)