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

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

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

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

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

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

"Коду гриф присвоить нельзя от слова вообще."
А если в коде "зашиты" нормированные показатели? Или формулы какие либо?)))

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

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

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

Евгений | 69782

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

Неужто здесь нет толковых спецов по НСД, которые могут пояснить вопрос выше?

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

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

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

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

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