Шрифт:
Интервал:
Закладка:
— там, где используются услуги доверенного органа (например, с целью применения цифровых подписей или цифровых сертификатов), ИБ является встроенной и неотъемлемой частью всего процесса управления сертификатом/подписью от начала до конца.
Степень применяемых мер защиты должна быть сопоставимой с уровнем риска, связанным с каждой формой транзакции прикладного сервиса. Транзакции должны соответствовать правовым и нормативным требованиям, под юрисдикцией которых они совершаются и хранятся.
10.2. ИБ при разработке ИС
Цель: Обеспечить разработку и внедрение ИБ в рамках жизненного цикла разработки ИС.
ИБ при разработке ИС определяют следующие составляющие:
— политика ИБ при разработке;
— управление изменением ИС;
— анализ приложений после изменений ОП;
— ограничение изменений пакетов программ.
ИБ при разработке ИС обеспечивают следующие меры:
— разработка безопасных систем;
— безопасность среды разработки;
— аутсорсинг разработки;
— тестирование безопасности;
— приёмное тестирование.
Политика ИБ при разработке
Меры и средства
В организации должны быть установлены и применены правила разработки ПО и ИС для разработок внутри организации.
Рекомендации по реализации
Безопасная разработка является требованием для создания безопасного сервиса, архитектуры, ПО и системы. В политике безопасной разработки необходимо предусмотреть следующие аспекты:
— безопасность среды разработки;
— руководство по безопасности жизненного цикла разработки ПО:
• безопасность методологии разработки ПО;
• правила написания безопасного кода для каждого используемого языка программирования;
— требования безопасности в фазе проектирования;
— контрольные точки безопасности на этапах проектирования;
— безопасные хранилища;
— безопасность контроля версии;
— требуемые знания по безопасности ПО;
— способность разработчиков избегать, находить и фиксировать уязвимости.
Следует использовать безопасные методы программирования как для новых разработок, так и повторного использования сценариев кодирования, если применяемые для разработки стандарты невозможно изучить или не соответствуют лучшим практикам.
Следует изучить стандарты безопасного кодирования и, по возможности, использовать. Разработчиков следует обучить их использованию и проверять их использование путем тестирования и анализа кодирования.
Если разработка находится в аутсорсинге, организация должна убедиться, что аутсорсинговая организация применяет эти правила для безопасной разработки.
Разрабатываться могут также внутренние приложения, такие как офисные приложения, сценарии, браузеры и базы данных.
Управление изменением ИС
Меры и средства
Изменениями в системах в течение жизненного цикла разработки следует управлять, используя формальные процедуры управления.
Рекомендации по реализации
Формальные процедуры управления изменениями должны документироваться и обеспечивать уверенность в целостности систем, приложений и продуктов с самых ранних стадий разработки на протяжении всех последующих сопровождающих усилий.
Внедрение новых систем и серьезных изменений в действующие системы должно следовать формальному процессу документирования, детализации, тестирования, контроля качества и управляемой реализации.
Этот процеес должен включать оценку риска, анализ влияний изменений и конкретизацию необходимых мер безопасности. Этот процесс должен давать уверенность, что существующие процедуры безопасности и управления не скомпрометированы, программисты получили доступ только к тем частям системы, которые необходимы им для работы, и формальное соглашение и разрешение на любое изменение получено.
При практической возможности следует обеспечить интеграцию процедур управления изменениями ОС и приложений.
Процедуры управления изменениями должны включать (но не ограничиваться):
— ведение учета согласованных уровней полномочий;
— обеспечение изменений, введенных уполномоченными пользователями;
— анализ мер защиты и процедур целостности на предмет уверенности того, что они не скомпрометированы изменениями;
— идентификация всех субъектов ПО, информации, баз данных и аппаратных средств, требующих изменений;
— идентификация и выбор критического кода безопасности для минимизации вероятности проявления известных слабых мест безопасности;
— получение формального одобрения на детальные предложения по изменениям перед началом работы;
— одобрение уполномоченного пользователя всех изменений до их реализации;
— обновление комплекта системной документации после завершения каждого изменения, архивирование или удаление старой документации;
— управление версиями ПО для всех обновлений;
— изменение операционной документации и процедур пользователя происходит настолько, насколько это необходимо;
— внедрение изменений в согласованное время и без нарушений бизнес-процессов.
Изменение ПО может привести к изменению среды и наоборот.
Передовой опыт рекомендует проведение тестирования нового ПО в среде, отделенной от сред разработки и производства. Это позволяет контролировать новое ПО и дает дополнительную защиту операционной информации, которая используется для тестирования.
Автоматическое обновление системы обеспечивает быстроту и удобство этого процесса, но повышает риск для целостности и доступности системы. Автоматическое обновление не следует применять в критичных системах, поскольку оно может вызвать нарушение критичный приложений.
Анализ приложений после изменений операционной платформы
Меры и средства
После изменений операционной платформы следует провести анализ и тестирование критичных бизнес-приложений на предмет отсутствия негативного влияния на деятельность и безопасность организации.
Рекомендации по реализации
Этот процесс должен охватывать:
— анализ прикладных программ и процедур целостности на предмет отсутствия нарушений после изменений операционной платформы:
— своевременное поступление уведомлений об изменениях, чтобы дать возможность перед их реализацией провести соответствующие тесты и анализы:
— внесение соответствующих изменений в планы обеспечения непрерывности бизнеса.
Операционные платформы включают в себя ОС, базы данных и межплатформенное ПО (взаимодействия системного и прикладного ПО).
Ограничение изменений пакетов программ
Меры и средства
Модификации программных пакетов должны не одобряться, а ограничиваться минимально необходимыми изменениями, и все изменения строго контролироваться.
Рекомендации по реализации
Насколько возможно, пакеты ПО, поддерживаемые поставщиком, должны использоваться без модификации. В случае необходимости модификации пакета программ, следует учитывать следующее:
— риск компрометации встроенных средств контроля и процедур целостности;
— необходимость получения согласия поставщика ПО;
— возможность получения требуемых изменений от поставщика в качестве стандартной программы обновления;
— последствия в случае, если организация в результате внесенных изменений станет ответственной за дальнейшее сопровождение ПО;
— совместимость с другим ПО при использовании.
При необходимости изменений их следует вносить в созданную копию ПО, а оригинальное ПО сохранить без изменений. Следует внедрить процесс управления обновлениями ПО, чтобы быть уверенным, что самые последние патчи и обновления приложений установлены во всем разрешенном ПО.
Все изменения должны быть полностью протестированы и задокументированы так, чтобы их можно было повторно использовать, при необходимости, для будущих обновлений ПО. Если требуется, модификации должны быть протестированы и утверждены независимым экспертом.
Разработка безопасных систем
Меры и средства
Принципы разработки безопасных систем должны быть установлены, задокументированы, поддерживаться и применяться при реализации ИС.
Рекомендации по реализации
Процедуры разработки безопасных ИС, основанные на принципах безопасности разработки, должны быть установлены, задокументированы и применены при разработке внутренней|собственной| ИС. Безопасность следует внедрять|намериться, разработать| на всех уровнях архитектуры ИС (бизнес|дело|, данные, приложения|приложение| и технология), согласовуя|уравновешивает| требования ИБ и доступности|достижимости|. Новую технологию следует проанализировать на предмет рисков|рисковый| безопасности и способности противостоять известным шаблонам атак|атаки|.
Принципы и установленные|утверждается| процедуры разработки следует регулярно пересматривать, чтобы гарантировать их соответствие современным стандартам|знамени| безопасности для процесса разработки. Их также следует регулярно пересматривать, чтобы гарантировать их соответствие современному уровню противодействия новым потенциальным угрозам, технологического прогресса|продвижению, авансу| и применяемых решений.
Принятые|утверждается| принципы безопасности разработки следует применять, по|куда| возможности, к аутсорсингу ИС посредством контрактов и других обязательных соглашений между