ГОСТ Р МЭК 60880—2010
5.7.2 Проект защищенности
5.7.2.1 Требования к контрмерам при проектировании конкретного программного обеспечения, полу
ченные при анализе защищенности, должны быть включены в требования к проектированию программного
обеспечения.
5.7.2.2
Л
юбое новое программное обеспечениедолжно проектироваться так, чтобы минимизировать
уязвимость системы.
5.7.2.3
Л
юбому ранее разработанному программному обеспечению нужно придать такие конфигура
цию и параметры, чтобы минимизировать уязвимость системы, например, путем минимизации функций до
необходимого предела или с помощью существующих функций защищенности программного обеспече
ния.
5.7.2.4 Должна быть исключена возможность изменения хранящихся программ оператором.
5.7.2 5
Если для выполнения функций К&У оператору необходим доступ к изменению данных,
то устройства человеко-машинного интерфейса должны ограничивать этотдоступ необходимыми преде
лами.
57.2.6 Там. где необходимо противостоять возможным угрозам защищенности, должны быть вклю
чены в проект, конфигурацию и/или процедуру присвоения параметров программного обеспечения эффек
тивные защитные меры, касающиеся:
- управления выборочногодоступа пользователя к функциям программного обеспечения:
- связи данных с системами, имеющими меньшую важность для безопасности;
- прослеживаемости модификаций программного обеспечения или параметров.
5.7.27 В проектной документации должны быть определены и описаны функции, критическиедля
защищенности, и элементы защищенности, примененные в программном обеспечении.
57.2.8 Во время верификации программного обеспечения должна быть подтверждена защищенность
функций.
57.2.9 Во время валидации СКУ с помощью подходящих тестов должна быть продемонстрирована
эффективностьфункций защищенности.
5.7.3 Доступ пользователя
57.3.1 Там. где необходимо, программное обеспечение должно поддерживать технические меры по
эффективной процедуре аутентификации, прежде чем пользователю будет разрешен доступ.
57.3.2 Там. где доступ пользователя является элементом, критическим для защищенности, в про
граммном обеспечении следует применять процедуру аутентификации, осуществляемую техническими
средствами на основе получения комбинации информации о знании (например, пароль), личной собствен
ности (например, ключ, карта с встроенным микропроцессором) и/или персональных характеристиках (на
пример. отпечаток пальца), а не полагаться исключительно на пароль.
57.3.3 Программному обеспечению и основанному на ролевом имени управлению доступом долж
ны бытьсообщены такие конфигурация и параметры, которые ограничивают разрешенныйдоступ пользо
вателя к функциям и данным необходимыми пределами.
57.3.4 Права доступа пользователя должны быть ограничены до определенной степени с учетом
возможностей и последствий потенциальных угроз защищенности.
Одним из возможных путей правильной реализации этого требования является криптографический
метод (шифрование данных).
57.3.5 Удаленные доступы из любых мест, находящихся вне технической среды станции (например,
из административных зданий или из мест, находящихся вне станции), способных повлиять на функции
программного обеспечения или данные, недопускаются.
5.7.4 Защищенность во время разработки
57.4.1 Жизненный цикл безопасности разработки программного обеспечения должен учитывать по
тенциальные угрозы защищенности во время деятельности по разработке и обслуживанию.
57.4.2 Должны быть предусмотрены меры противскрытых функций в прикладном программном обес
печении или системном программном обеспечении (например, верификация кода), т.к. они могут поддер
живать потенциальный несанкционированныйдоступ.
57.4.3 Если меры против скрытых функций не могут быть реализованы в отношении ранее разрабо
танного программного обеспечения, применение такого программного обеспечения может быть обосновано с
учетом потенциальной угрозы обеспечения безопасности, важности безопасности функций контроля и
управления (1&С). характеристик системы и программного обеспечения.
12