Контроль на наличие НДВ - Форум по вопросам информационной безопасности

2malotavr
Ну и какое отношение имеет OS и российские промышленные СУБД, АСУ ТП к
"Программному обеспечению средств защиты информации" которые контролируют на НДВ?

Только если туда что-то подобное встроено.
Это разве детерминировано?
Что за особый изыск в подобном передергивании?
Только чтобы уесть?

2Александр - просмотрите буржуйские методики по пентесту и по quality testing - там что-то близкое к теме, при контроле качества софта.
У нас это вотчина ГАММЫ - РАМЭК и прочих лабораторий все их методики это ноу-хау заточенное на то оборудование которое в наличии а не на то что реально нужно - поэтому у пользователей искомина на тему.

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

То же самое касается и многих других систем. Я вам больше скажу: как-то приходилось участвовать в исследованиях софта, предназначенного для системы военного назначения с высоким грифом секретности. Так вот даже там приходилось по факту полагаться на встроенные функции управления доступом импортного прикладного софта (по бумагам система, естественно, проходила как класс 3А и функции управления доступом в ней якобы не требовались).

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

2malotavr
Приведенный Вами частный случай имеет место быть.
Но Вы внимательно прочтите название нормы на которую ссылались Выше - она не претендует на всеохватность - здесь обьект регулирования СЗИ.
НЕТ СЗИ нет регулирования!
Мое мнение - для приведенных Вами случаев должны быть разработаны свои нормы.
Их нет - это моя вина?
В моих сообщениях не было высказываний типа:"все козлы, одни мы тут д'Артаньяны" звучат, мягко говоря, опрометчиво" - это прямая цитата из Вас.
Так кто это написал?
И вообще мне непонятны постоянные нападки на ПРИВАТНОСТЬ - которую Вы (наверное по простоте душевной?) толкуете как анонимность.
Здесь каждый выбирает для себя.
А в полицейском государстве где даже намек на инакомыслие - уже преступление против правящей клики, думаю Ваша позиция вообще ВРЕДИТЕЛЬСКАЯ.
Мне не нужны никакие хлопоты в судах, где решения пишутся до рассмотрения - а ВАМ?
А с мнением - "люди, работающие над защитой таких систем, не глупее нас с вами. Они просто делают то, что в данных условиях возможно теми средствами, которые в данный момент доступны" - почти соглашусь.
Если НЕТ ничего из доступного - это повод ничего не делать и молча в тряпочку соучаствовать в преступлении?
Спросите громко у Кудрина (чтобы услышал) - а деньги на ИБ в бюджете где?
И в акте приемки оборонной системы впишите свое частное мнение.
С неизменным почтением к Вашему частному мнению

> Но Вы внимательно прочтите название нормы на
> которую ссылались Выше - она не претендует на
> всеохватность - здесь обьект регулирования СЗИ.

Можно подумать, мы первый день знакомы. :) Z знаю, что объектом регулирования являются СЗИ. Вот только, считая, что к СЗИ относятся только программные продукты специального назначения, вы глубоко заблуждаетесь :)

> Мое мнение - для приведенных Вами случаев должны быть разработаны свои нормы.

Эти нормы УЖЕ разработаны. "Положение о сертификации СЗИ" - всего лишь верхнеуровневый документ, который раскрывается нормативными актами системы сертификации РОСС RU вообще и РОСС RU.0001.01БИ00 в частности. Согласно этим нормативным актам под СЗИ понимаются не только специализированные средства защиты, но и программные средства общего назначения, функции безопасности которых применяются для защиты охраняемых законом сведений.

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

Только если туда что-то подобное встроено.
Это разве детерминировано?

Не факт!
- об этом Вы и говорили Выше с болью за отсутствие оных
Ну что мы школяры разве?
Давайте больше друг - друга уважать и не стоит надергивать и притягивать...право НЕ стоит!

Здравствуйте,

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

Предположим, имеется некая сложная многопользовательская система иностранного производства (например, какая-нибудь АСУТП, ERP, ГИС система). Разумеется, там есть встроенные средства авторизации пользователей. В её БД может храниться конфиденциальная информация, и вполне вероятно, информация, представляющая гостайну. Встроенной криптографии нет, сама система поставляется (продается) как софт на CD, а не как программно-аппаратный комплекс.
Что именно в такой системе нужно сертифицировать и предоставлять в сертификационные органы? Только тот модуль/кусок кода, где осуществляется авторизация пользователей (так как сертифицируется СЗИ), или всю систему целиком (исходные тексты всех модулей, включая прикладные, исходные тексты проприетарной СУБД, интерфейсы, GUI, описание встроенного компилятора проприетарногоязыка программирования, и т.д.), или же комплекс система + операционная система, установленная на определенном железе с сопутствующими сертифицированными системами криптографии, авторизации, СЗИ НСД?
Как я понял, прочитав РД на НДВ и документы РД ФСТЭК, нужно предоставлять исходные тексты на систему, контрольные суммы файлов, полное описание системы согласно ГОСТам 19xxx - это вообще реально? Хорошо, предположим, все предоставлено и проверено, но потом выпускаются патчи, выходят новые релизы системы, а системный интегратор, внедряющий систему, будет делать кастомизацию на местах, и реальная система (контрольные суммы файлов) будет отличаться от того, что было заявлено на сертификацию... заново сертифицировать?

Спасибо

2Евгений
...
Хорошо, предположим, все предоставлено и проверено, но потом выпускаются патчи, выходят новые релизы системы, а системный интегратор, внедряющий систему, будет делать кастомизацию на местах, и реальная система (контрольные суммы файлов) будет отличаться от того, что было заявлено на сертификацию... заново сертифицировать?...
Именно так...
Все сначала...и так бесконечно
- в этом проблема.
Попробуйте прикрутить себе средства доверенной загрузки и контроля CRC.
Больше контактируйте со своими кураторами от ФСТЭК - зачем вам чужие (непроверенные) мнения которые могут не совпадать с мнением ФСТЭК?

Спасибо,
На сайте IBM (возьмем их как пример) прочитал, что они сертифицировали некоторые свои продукты по 4 уровню контроля по защите от НДВ, что позволяет использовать продукты при построении АС класса защищенности до 1Г включительно. А потом каждый апдейт сертифицируется отдельно и распространяется, без необходимости сертифицировать всю систему заново.
Иными словами, программный продукт сертифицируется на отсутствие НДВ, а аттестация на класс защищенности проводится уже на весь комплекс в целом, который может включать уже сам продукт, установленный на сертифицированную Win XP и защищенный сертифицированными системами СЗИ НСД и криптографией, внутри охраняемого периметра с солдатом с ружьем... То есть сертификация нужна ТОЛЬКО на НДВ, и не нужно дорабатывать продукт для обеспечения, например, биометрической авторизации и шифрования ОЗУ/HDD?

> Что именно в такой системе нужно сертифицировать и предоставлять в сертификационные органы?

Сертифицируют реализацию функций безопасности. Описывают из в форме ЗБ или ТУ - и сертифицируют.

> Только тот модуль/кусок кода, где осуществляется... или всю систему целиком ... или же комплекс система + ... ?

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

> Как я понял, прочитав РД на НДВ и документы РД ФСТЭК, нужно предоставлять исходные тексты на систему, контрольные суммы файлов, полное описание системы согласно ГОСТам 19xxx - это вообще реально?

Перефразируя классков: "это более чем реально - это неизбежно". :)

Если у вас есть предметный вопрос относительно определенного продукта, который вы хотите сертифицировать - лучше обсуждать его. Для наших продуктов мы давали сертификаторам возможность поработать с нашими исходными кодами (с соответствующими мерами защиты от несанкционированного их копирования), документацию по ГОСТ 19 (описание программы, описание применения, руководство по инсталляци, руководство администратора, руководство пользователя), формуляр с контрольными суммами в качестве приложения к нему. На самом деле это не так сложно, как кажется на первый взгляд, хотя в каждом продукте, с сертификацией которого мне приходилось сталикваться, были особености, которые приходилось разруливать в индивидуальном порядке.

> ...но потом выпускаются патчи...

Это - самая большая проблема, не позволчяющая использовать сертифицированные образцы общесистемного программного обеспечения для практического обеспечения защиты. Вы не можете ставить патчи на сертифицированный софт, пока их не "досертифицируют", а это - лаг в 3 месяца минимум. Тем более, что никто не сертифицирует каждый отдельный патч. На сеголняшний день проблема решения не имеет.

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

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

> На сайте IBM ... прочитал... То есть сертификация нужна ТОЛЬКО на НДВ, и не нужно дорабатывать продукт для обеспечения, например, биометрической авторизации и шифрования ОЗУ/HDD?

Вы прочитали неправильно. Там написано, что оно сертифицировано на НДВ и на ТУ/ЗБ. Сертификация только на НДВ, как правило, не проводится, потому что сама по себе она на фиг никому не нужна.

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

Спасибо за разъяснения. Стало немного понятней, но все же целостной картины я пока не составил.
Сразу прошу прощения за много букв;) ИБ не обучался, кроме РД и ГОСТов реальных примеров сертификации не видел, поэтому прошу совета специалистов.

Во-первых, что такое ТУ? не нашел такой аббревиатуры в контексте ИБ.

Во-вторых, я представляю примерный план действий и пререквизитов для сертификации/аттестации программного продукта зарубежного производства на класс защищенности 1А таким:

1) Подготовить документацию на ПО согласно ГОСТ 19.xxx-78, включая список файлов дистрибутива с контрольными суммами.
Достаточно проблематичный пункт ввиду того, что программа еще не локализована на русский язык, вся пользовательская документация на английском, сами разработчики все иностранцы, программная документация (описание алгоритмов, функций, процедур, переменных и т.д.) может и не существовать вовсе, или быть плохого качества, а если и есть - то на английском языке и явно не по ГОСТу 19.xxx-78.
Вопрос №1 - на какой Уровень Контроля ориентироваться и как он связан с Классами защищенности АС по ФСТЭК?
Вопрос №2 - кто должен подготавливать программную документацию по ГОСТу, если у компании-разработчика, которая хочет сертифицировать продукт, нет специалиста по ИБ? Может это быть некий системный интегратор с соответствующей экспертизой и лицензией ФСТЭК?

2) Предположим, сертификация на отсутствие НДВ пройдена по 3-му уровню контроля. Это еще не значит, что программа может использоваться в АС класса защищенности 1А. Для этого нужно пройти сертификацию по ЗБ/ТУ (?). Для этого нужно:

3) оформить Профили Защиты (ПЗ) в соответствии с ГОСТ Р ИСО/МЭК 15408-2002;
4) оформить Задание по Безопасности (ЗБ) также в соответствии с ГОСТ Р ИСО/МЭК 15408-2002;
(по идее это должно было быть сделано архитекторами ПО как требования программистам еще во время разработки программы, но в нашем случае ПО уже готово)
Вопрос №3- если по каким-то параметрам возможности программы в плане авторизации, аутентификации и аудита (СЗИ НСД) не соответствуют требуемым профилям защиты, то придется отправлять ПО на доработку, или дополнять АС сторонними сертифицированными продуктами?.
Вопрос №4 - на какой Оценочный Уровень Доверия ориентироваться в ЗБ и ПЗ? Как ОУД связан с Классами защищенности АС по ФСТЭК?

5) построить некий комплекс, который будет проходить аттестацию, включающий сертифицированную ОС и железо, сертифицированные продукты для биометрической аутентификации пользователей, для криптографии, для контроля доступа к внешним носителям, и т.д.
Вопрос №5 - программная документация на ПО описывает только собственное ПО, но не сторонние системы/железо. Кто выбирает, чем именно необходимо доукомплектовать программу, чтобы получить комплекс, удовлетворяющий классу 1x? ИМХО, тот же сист. интегратор может предложить эти продукты и совместно с разработчиком построить комплексное решение для аттестации.

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

В итоге получается 2 сертификата - по НДВ и по ЗБ.

В общем, мне это видится как-то так, если я что-то пропустил или неправильно истолковал, поправьте пожалуйста.

Спасибо,
С уважением,
Евгений