Форум | Новинки | Объявления | iMag | Подписка | Публикации журнала | Материалы

Новости проекта

Отраслевые новости

Угрозы

Преступления

Наказания

Партнеры


Журнал "Information Security"

Каталог "IT-Security"

Рекламодателям

Сотрудничество


Материалы

Форум

ITSec Weekly

Календарь

Публикации

Подписка

Контакты

Ссылки

Партнеры

Мероприятия

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

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

Средства разработки ПО на аттестованном АРМ

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


Страницы: < 1 2

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

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

Страницы: < 1 2

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

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



Добавить сообщение

Автор:
Компания:
E-mail:
Уведомлять о новых сообщениях в этой теме да
нет
Текст сообщения:
Введите код:









Реклама на сайте

ПОИСК

СВЕЖИЙ НОМЕР
ПОДПИСКА НА НОВОСТИ

 

 

 

 

Рейтинг@Mail.ru

Яндекс цитирования

Форум | Новинки | Объявления | iMag | Подписка | Публикации журнала | Материалы

Бесплатная подписка | Форум | Контакты | Ссылки | О чем этот сайт

Copyright © 2003-2013, ООО "Гротек"
Использование материалов сайта возможно при указании активной гиперссылки на главную страницу этого сайта. Ссылка должна выглядеть так: Itsec.Ru.