Средства разработки ПО на аттестованном АРМ - Форум по вопросам информационной безопасности

Адрес документа: http://lib.itsec.ru/forum.php?sub=13279&from=0

К списку тем | Добавить сообщение


Автор: Разработчик ПО, По разработке ПО | 69717 16.03.2017 17:11
Вопрос к тем, кто задумывался или имеет опыт прохождения аттестации в данном вопросе.
Требуется проводить разработку ПО на аттестованном рабочем месте (в связи с тем, что алгоритм функционирования и структура данных является с грифом С или пометкой ДСП).

Как легально установить средство разработки (IDE, компилятор) в обход требования РД АС по отсутствию средств разработки.

Как вариант ответа вижу включение такого средства в паспорт и указание в аттестате соответствия запрета на изменение объектного и исполняемого кода СЗИ на данном АРМ?

В похожей ветке нет ответа http://www.itsec.ru/forum.php?sub=12366&from=0&format=printer-friendly

Автор: WORM, MK | 69730 17.03.2017 11:36
Надо, чтобы по документам на АС проходило ее назначение и цель применения средств разработки ПО.
Т.е. сам Аттестат лучше назвать типа "Аттестат соответствия ...... на АС разработки ПО такого-то (или программных СЗИ). В техпаспорте то же. Возможность работы со средствами разработки желательно оговорить в аттестате.
Очень важно подробно расписать порядок работы с этим ПО в Описании техпроцесса, чтобы было понятно зачем оно там и кто с ним работает. В Разрешительной системе указать кто и как получает доступ к данному ПО, роль админа в контроле его применения только в нужных целях.
Т.е. нужно доказательная база того, что средства разработки там не случайно, А ДЛЯ РЕАЛИЗАЦИИ ТЕХПРОЦЕССА и достижения целей обработки инф-ции.
Будете подавать заявку на лицензию - распишите в Справке-отчете (пояснительной записке) подробнее: зачем вам в АС средства разработки, кто и как с ними будет работать (а документами по аттестации это должно быть подтверждено).

Насчет пометки ДСП подумайте, может ли она быть у вас. Не лучше ли "коммерч. тайна" (потому как ДСП может быть у госов и очень скоро ее будут защищать по 17-му приказу, тогда лучше 2 разных компа аттестовать: один под ГТ, другой под ДСП (по 17-му)).

Позвоните в отдел лицензирования ФСТЭК (окружной или даже центральный) не стесняйтесь. Попросите консультацию. Они вроде адекватно себя ведут. Правда, не факт, что консультировать будет тот эксперт, который ваше дело будет вести.

Автор: sekira | 69735 17.03.2017 12:44
"и очень скоро ее будут защищать по 17-му приказу"
А можно поподробнее почему так и что грядет? И куда деть СТР-К... :)))

"Они вроде адекватно себя ведут."
Ах..хаха

Речь про аттестацию АС ГТ, не про лицензирование по ТЗКИ. Собираетесь не выполнять РД АС? Как планируете обойти требования и где найдете орган готовый подставится?

Автор: nekto | 69739 17.03.2017 18:06
to Разработчик ПО, По разработке ПО | 69717

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

Автор: WORM, MK | 69741 17.03.2017 18:15
" А можно поподробнее почему так и что грядет? И куда деть СТР-К... :))) "

В 149-ФЗ вносится поправка, обязывающая защищать весь госинформресурс. Т.о. сфера применения приказа 17 будет расширена: выполнять эти требования нужно будет не только в ГИС, но и всюду, где этот самый госинформресурс обрабатывается. Если ДСП обрабатывает коммерсант или ГУП, МУП, то он будет обязан принимать меры по защите в соотв. с Пр.17.

Текст поправки в декабре был внесен в ГД.

СТР-К никуда девать не надо: методический документ по защите от УИТК, если такие угрозы где-то актуальны.

Автор: WORM, MK | 69742 17.03.2017 18:25
sekira, намекаете, что в России невозможно разработать секретный софт по причине наличия РД АС? :))

Автор: sekira | 69744 17.03.2017 19:14
"sekira, намекаете, что в России невозможно разработать секретный софт по причине наличия РД АС? :))"
Намекаю что кто то обходит требования РД НСД. Вопрос как? Думаю это краеугольный камень темы.
Как примерно я сталкивался но дискредитацией органов и регуляторов заниматься не хочу, вот и слежу кто ответит по существу.

Автор: WORM, MK | 69745 17.03.2017 19:27
Кто-то обходит, кто-то согласовывает с регулятором.
У "Старшего Брата" все еще хуже: конкретных требований может и вовсе не быть, а дело делать надо. Какой выход? Нужно идти к нему на поклон, согласовывать ТЗ - и вперед. Кому-то согласуют, а кому-то нет.

Автор: sekira | 69746 17.03.2017 20:54
"согласовывать ТЗ - и вперед."
Собственно об этом и вопрос!

Автор: Евгений | 69782 20.03.2017 09:47
А зачем обходить требования РД АС? Требования к 1Б подсистема целостности, ни слова про запрет на средства разработки.

Автор: CrBiNsk | 69784 20.03.2017 10:39
Фразу в РД я понимаю так, что к примеру компилировать, отлаживать можно (свое), а дизассемблировать СЗИ нельзя. Т. к. при разработке своего ПО дизассемблирование не нужно вообще - не вижу проблемы. Не ставьте в систему Дизассе́мблер — транслятор, преобразующий машинный код, объектный файл или библиотечные модули в текст программы на языке ассемблера.

Автор: oko | 69794 20.03.2017 12:26
Выделите машины со средствами разработки. Закройте к ним доступ организационно, то бишь без СЗИ НСД. Как максимум - СДЗ + АВЗ.
Выделите машину(машины) без средств разработки, но с текстовым редактором, программой записи CD, программой КЦ и программой-сборщиком дистрибутива разработанного на других машинах софта. Оборудуйте эту машину СЗИ НСД. Аттестуйте. Заведите дсп-носители (те же flash).
Техпроцесс:
1. Разработка ведется на АРМ, не оборудованных СЗИ НСД и не аттестованных.
2. Сборка, написание тех.документации, запись дистрибутива и его верификация - на аттестованном АРМ. Гриф по итогу присваивается конечному дистрибутиву и его сопровождающим документам.
Если очень хочется - все это можно объединить в одну сеть, используя не столько СЗИ НСД, сколько средства контроля сетевой активности и передачи данных. Чтобы с АРМ разработчиков на АРМ-С можно было передавать готовый код, а обратно (после сборки дистрибутива) нельзя.

Коду гриф присвоить нельзя от слова вообще. Это все равно что букварю (не тому Букварю, ага) присвоить гриф. В сущности, пример из разработки той же аттестационной документации - большая часть информации в этих документах не может являться ГТ по причине ее известности довольно широкому кругу лиц на объектах (размещение ОТСС, схемы, настройки, как выполняются требования и проч.) Все вместе - да, под "буковкой". С разработанным ПО тот же принцип.

ЗЫ Исключительно на правах imho. Тоже любопытно послушать, что и кто скажет.

ЗЗЫ С дизассемблером тоже есть косяк. Как и с остальными средствами отладки. Допустим, в аттестованной АС с СЗИ НСД отсутствуют средства отладки. Но присутствуют средства разработки. И это дает возможность скомпилить сплойт (а логику сплойта можно получить дома, воспользовавшись дизассемблером для дистрибутива СЗИ НСД, полученного достаточно просто - через Сеть, у ответственных лиц, иным путем). Т.е. вероятность утечки/атаки резко повышается, ежели в АС разрешены средства разработки ПО. Другой вопрос, что в той же Win можно спокойно писать батники или пользоваться vbs. Но на то и существует механизм ЗПС (ОПС). Отсюда понятна логика ФСТЭК, которая этот механизм требует к обязательному применению в любых АС.

Автор: Евгений | 69798 20.03.2017 14:01
"Коду гриф присвоить нельзя от слова вообще."
А если в коде "зашиты" нормированные показатели? Или формулы какие либо?)))

Автор: oko | 69804 20.03.2017 17:24
to Евгений
Нехрен делать это в коде. Для таких вещей в мире существуют конфиг-файлы. Даже для формул (все от рук программиста зависит). Которые позже можно добавить в дистрибутив на этапе сборки в памяти аттестованного АРМ.

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

И, кстати, да, согласовать со ФСТЭК подобные АС возможно. Знаю, видел даже (с)

Прошла пара недель

Автор: utyf | 70689 10.04.2017 13:35
Евгений | 69782

Возник в связи с указанным ответом вопрос: если не указано чётко для АС 1 класса в РД, что в них не должно быть средств разработки и отладки программ, означает ли это, что эти самые средства там могут быть (например, разрабатывается грифованное ПО)? И ещё вопрос: что подразумевается под средствами модификации объектного кода программ (пример)?

Автор: utyf | 70822 12.04.2017 11:02
Неужто здесь нет толковых спецов по НСД, которые могут пояснить вопрос выше?

Автор: oko | 70831 12.04.2017 13:46
to utyf
Все ответы были даны ранее. Вместо переливания из пустого в порожнее и попыток найти в РД неточности или двоякости формулировок, лучше задумайтесь, как наличие политики разграничения доступа субъектов (пользователей) к объектам (файлы и каталоги) может защитить от написания сплойта из-под СЗИ НСД для самой СЗИ НСД при помощи штатных (инсталлированных) средств разработки? А именно этим различаются 1 и 2 классы АС...

Автор: Евгений | 70832 12.04.2017 13:57
utyf | 70689
"И ещё вопрос: что подразумевается под средствами модификации объектного кода программ (пример)? "
Отладчики, дебаггеры и т.п. которые позволяют изменять код программы "на ходу".

"Возник в связи с указанным ответом вопрос: если не указано чётко для АС 1 класса в РД, что в них не должно быть средств разработки и отладки программ, означает ли это, что эти самые средства там могут быть (например, разрабатывается грифованное ПО)?"
Да, они там могут быть, но не забывайте про требование "качеством приемки программных средств в АС, предназначенных для обработки защищенных файлов". Еще лучше проконсультироваться с органом по аттестации или же с местным управлением ФСТЭК

Автор: sekira | 70836 12.04.2017 14:49
"или же с местным управлением ФСТЭК"
с местным бесполезно ... низя и все.
попробуйте с центральным... ну или подождите скоро будут новые требования взамен РД.

Автор: Yerdan, MMZ | 70894 14.04.2017 18:45
В свое время у нас поднимался такой вопрос, недавно снова возник. В РД действительно прописано, что целостность программной среды защищается В ТОМ ЧИСЛЕ отсутствием средств разработки ПО. К тому же, зачастую для исполнителей, разрабатывающих ПО, требуются права администраторов, что вообще противоречит всем нормативным документам. К тому же надо учитывать, что имея в своем распоряжении средства разработки, теоретически можно написать скрипт или программу, позволяющую получать доступ в обход СЗИ.
В нашем УФСТЭК это прокоментировали так: Мы должны обеспечить защиту информации. Если согласно техпроцессу надо средства разработки ПО, если надо дать пользователям права администраторов - защищайтесь организационно. К примеру, выделение для этого дела отдельного компьютера, располагаемого в отдельном помещении с контролем доступа. Кроме разработчиков ПО никого к компу не допускать. Если разрабатывается разное ПО и есть разграничение доступа к нему, то все исходные коды - на различных съемных носителях. Охрану посадите, чтобы не вытащили ваше секретное ПО, наконец.

Прошла пара месяцев

Автор: Александр | 72686 13.06.2017 18:16
Коллеги, поднимаю этот вопрос.
РД ФСТЭК "АС.Защита от НСД к информации. Классификация АС и требования по защите информации" от 30.03.1992 начиная с класса защищенности 3Б выдвигаются требования к подсистеме обеспечения целостности, причем в п.2.5 указано, что "целостность программной среды обеспечивается отсутствием в АС средств разработки и отладки программ". У нас на аттестованных машинах для работы должны быть установлены Delphi 10.1 Berlin Professional и Visual Studio. Как понимаю - классические средства разработки. Значит - нельзя ставить. Но где (как уже отмечалось) разрабатывать ПО? И еще - в РД по Ас в требованиях к целостности для класса 1Б указано следующее - "целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации". О чем думали разработчики этого РД в далеких 1991-92 годах, когда выдвигали это требование. Ежеквартальный инструментальный контроль осуществляется, проверяются контрольные суммы программы - DL 8с в нашем случае. При каждой загрузке DL также проверяется целостность. Так что - испортить СЗИ достаточно сложно.
Ваши мнения, коллеги?

Автор: oko | 72687 13.06.2017 21:01
Все допустимые мнения в этой же теме форума уже были озвучены в полной своей мере и степени. А что до "...трансляторов с языков высокого уровня и средств модификации объектного кода...", то и ежу понятно, что средствами SoftICE/OllyDbg (с соответствующим плагинами) можно попытаться (не факт, что получится, но попытка возможна) переопределить области памяти и вызовы программной части СЗИ НСД. А в ЗГТ и за попытку можно по шапке схлопотать... Особенно с учетом веяний последних лет на повальное выявление уязвимостей в сертифицированных средствах защиты...

ЗЫ Сменили бы вы язык... "секретные apps for Vedroid" все равно не имеет смысла лепить, а в остальном лучше сразу вернуться к истокам и ваять на turbo pascal... под Эльбрус, ага...

Автор: Александр | 72688 13.06.2017 23:22
to oko
А кто мешает дизассемблировать СЗИ на другом компьютере? Купили DL или SN (например) поставили на обычные ПК и ищите в них уязвимость. А нашли - так злоумышленник под видом обычного пользователя приходит на аттестованный АРМ и получает доступ в нарушение имеющихся правил.
Вопрос в том, что при запуске СЗИ - они проверяют целостность и если есть нарушения, то и не запустятся. А РД писали в конце 80-х годов и в те самые дни августа 91-го, когда вообще было непонятно - что будет с государством, Гостехкомиссией и т.д. Поэтому я и спрашиваю - есть ли регламентированный выход из этой ситуации? Как и с криптографией - читаем, что криптография в классе 1Б нужна, но в другом документе указано, что если ..., то не обязательна. Так может быть и здесь вопрос может быть решен - напишу в ежеквартальном отчете, что проверяем контрольные суммы и т.д. хоть ежедневно с записью в журнал.

Автор: sekira | 72846 14.06.2017 07:11
Пишут ТЗ. Согласуют с ФСТЭК. Аттестуют. Не каждый орган берется за подобную аттестацию.

Автор: oko | 72850 14.06.2017 12:14
to Александр
Можете и на соседней машине. Главное, чтобы не могли на аттестованной. И выявление уязвимости (через отладку и декомпиляцию) - это не самоцель. Главное - это невозможность влияния на используемую программную часть СЗИ в процессе ее работы. Что, кстати, согласуется с требованиями по ОЦЛ даже в случае динамического контроля целостности. Разъясняю: этот тип КЦ не постоянный, но все-равно периодический, т.е. определенные временные промежутки, когда код СЗИ в оперативной памяти не самоконтролируется, все равно имеются - по требованиям РД, разумеется. Так что не катите бочку на создателей РД. Они молодцы - в то время сделать документ, который до сих пор жив и имеет право на существование (в целом, разумеется) - показатель очень качественной работы...
А с криптографией... Тут скорее политический вопрос двух регуляторов. Поэтому в "другом документе" и сказано про возможность отказа от криптографии. Сами же должны понимать...

Автор: ALXNV | 72851 14.06.2017 14:07
Коллеги, много раз перечитал РД, в классеклассе 1б нет требований к отсутствию средств разработки, и требования с предыдущих классов не идут дополнением.

Автор: oko | 72852 14.06.2017 14:21
to ALXNV
Во-первых, таких систем (1Б) не так много...
Во-вторых, для разработки закрытого ПО не многие пойдут на создание АС с "двумя буковками"...
В-третьих, скоро это перестанет иметь какое-либо значение... ждем соответствующую литературу, так сказать...

Прошло около недели

Автор: Александр | 73018 22.06.2017 14:35
to oko
Действительно - в 1В указано "целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ при обработке и (или) хранении защищаемой информации", а в 1Б - "целостность программной среды обеспечивается качеством приемки программных средств в АС, предназначенных для обработки защищенных файлов".
Такое впечатление, что в классе 1Б в вопросе обеспечения целостности требования более слабые, чем в предыдущих классах, хотя этого быть не должно! И что такое качество приемки СЗИ? Одни и те же программы (SN, DL-8c) Могут работать до 1Б включительно. Поэтому, если есть возможность - то по 1Б. Единственное - нужно проводить ежеквартальный контроль, но, поскольку своими силами, то незатратно.

Автор: Евгений | 73019 22.06.2017 14:57
Александр | 73018
"И что такое качество приемки СЗИ?"
Не СЗИ, а программных средств АС предназначенных для обработки защищаемой информации. Т.е. к программам которые Вы пишите при помощи средств разработки.

Автор: oko | 73020 22.06.2017 15:00
to Александр
Качество приемки программных средств, предназначенных для обработки ИОД, а не СЗИ. Т.е. устанавливать только "доверенные" программы для работы с электронными файлами, содержащими ГТ. Фактически, таких нет (кроме прошедших проверку по НДВ до 2 уровня контроля). Вот и думайте, в каком классе требования выше или ниже...
И откуда фраза про ежеквартальный контроль, и контроль чего?

Автор: Александр | 73021 22.06.2017 15:53
to oko
По РД - 2.14. Требования к классу защищенности 1Б:
- должно проводиться периодическое тестирование всех функций СЗИ НСД с помощью специальных программных средств не реже одного раза в квартал;
Этим и отличается (фактически 1Б от 1В). Но раз в квартал проверить контрольные суммы DL (или SN), антивирусника Трафаретом (или Фиксом), а также с помощью Терьера проверить, как удаляются удаленные файлы - несложно.

Автор: Евгений | 73022 22.06.2017 16:10
Александр | 73021
Забыли еще про разграничение доступа типа Ревизоров.

oko | 73020
"Т.е. устанавливать только "доверенные" программы для работы с электронными файлами, содержащими ГТ. Фактически, таких нет (кроме прошедших проверку по НДВ до 2 уровня контроля). Вот и думайте, в каком классе требования выше или ниже..."
Эмм, а причем здесь доверенное ПО и НДВ2, раз мы говорим про разработку ПО на АС класса 1Б? Насколько я понимаю, должен быть разработан и внедрен механизм качества приемки созданного ПО и которым подтверждается, что созданное ПО не влияет на состояние защищенности объекта.

Автор: Сергей, ОГВ | 73023 22.06.2017 17:21
Для oko
А почему качество приёмки - это установка "доверенных" программ (т.е. я как понимаю прошедших НДВ).
Согласно ГОСТу Приёмка программных средств заключается в приёмочном осмотре и в приёмочном тестировании, т.е. выполнении "контрольного примера".

Автор: oko | 73026 22.06.2017 19:32
to Сергей
А спросите тов. malotavr, как у нас на НДВ проверяют. Те же контрольные примеры, только, пожалуй, в бОльшем диапазоне...
Выше писал про идеальный случай, который, благо, пока не обязателен. И, кстати, вы когда-нибудь при разработке/эксплуатации/аттестации АС 1Б какое-либо ППО в ней "приемочно тестировали"? Или, так сказать, опирались на жизненный опыт, что тот же MS Office при любом раскладе будет выполнять нужный функционал? В том и суть...

Автор: oko | 73027 22.06.2017 19:39
to Евгений
Ваш пост что-то проглядел... Не суть - ответил уже тов. Сергею (ОГВ)...

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

ЗЫ Помимо всего прочего, imho, "качество приемки программных средств в АС" подразумевает, что в них отсутствует недекларированный функционал, а также функционал, напрямую не связанный с обработкой ГТ в электронном виде. Аля те же отладчики, дебаггеры и дизассемблеры. А если пытаться под эту формулировку подтянуть идею "для обработки ГТ нужны отладчики, потому что софт ГТшный => приемка таких ПС допустима в 1Б", то, повторю мысль, высказанную ранее - это, imho, бред, и в самом коде ничего секретного быть не может и быть не должно...

Просмотров темы: 8572


Copyright © 2004-2019, ООО "ГРОТЕК"

Rambler's Top100 Rambler's Top100