Управление информационной безопасностью. Стандарты СУИБ

Следует использовать безопасные методы программирования как для новых разработок, так и повторного использования сценариев кодирования, если применяемые для разработки стандарты невозможно изучить или не соответствуют лучшим практикам.

Следует изучить стандарты безопасного кодирования и, по возможности, использовать. Разработчиков следует обучить их использованию и проверять их использование путем тестирования и анализа кодирования.

Если разработка находится в аутсорсинге, организация должна убедиться, что аутсорсинговая организация применяет эти правила для безопасной разработки.

Разрабатываться могут также внутренние приложения, такие как офисные приложения, сценарии, браузеры и базы данных.

Управление изменением ИС

Меры и средства

Изменениями в системах в течение жизненного цикла разработки следует управлять, используя формальные процедуры управления.

Рекомендации по реализации

Формальные процедуры управления изменениями должны документироваться и обеспечивать уверенность в целостности систем, приложений и продуктов с самых ранних стадий разработки на протяжении всех последующих сопровождающих усилий.

Внедрение новых систем и серьезных изменений в действующие системы должно следовать формальному процессу документирования, детализации, тестирования, контроля качества и управляемой реализации.

Этот процеес должен включать оценку риска, анализ влияний изменений и конкретизацию необходимых мер безопасности. Этот процесс должен давать уверенность, что существующие процедуры безопасности и управления не скомпрометированы, программисты получили доступ только к тем частям системы, которые необходимы им для работы, и формальное соглашение и разрешение на любое изменение получено.

При практической возможности следует обеспечить интеграцию процедур управления изменениями ОС и приложений.

Процедуры управления изменениями должны включать (но не ограничиваться):

– ведение учета согласованных уровней полномочий;

– обеспечение изменений, введенных уполномоченными пользователями;

– анализ мер защиты и процедур целостности на предмет уверенности того, что они не скомпрометированы изменениями;

– идентификация всех субъектов ПО, информации, баз данных и аппаратных средств, требующих изменений;

– идентификация и выбор критического кода безопасности для минимизации вероятности проявления известных слабых мест безопасности;

– получение формального одобрения на детальные предложения по изменениям перед началом работы;

– одобрение уполномоченного пользователя всех изменений до их реализации;

– обновление комплекта системной документации после завершения каждого изменения, архивирование или удаление старой документации;

– управление версиями ПО для всех обновлений;

– изменение операционной документации и процедур пользователя происходит настолько, насколько это необходимо;

– внедрение изменений в согласованное время и без нарушений бизнес-процессов.

Изменение ПО может привести к изменению среды и наоборот.

Передовой опыт рекомендует проведение тестирования нового ПО в среде, отделенной от сред разработки и производства. Это позволяет контролировать новое ПО и дает дополнительную защиту операционной информации, которая используется для тестирования.

Автоматическое обновление системы обеспечивает быстроту и удобство этого процесса, но повышает риск для целостности и доступности системы. Автоматическое обновление не следует применять в критичных системах, поскольку оно может вызвать нарушение критичный приложений.

Анализ приложений после изменений операционной платформы

Меры и средства

После изменений операционной платформы следует провести анализ и тестирование критичных бизнес-приложений на предмет отсутствия негативного влияния на деятельность и безопасность организации.

Рекомендации по реализации

Этот процесс должен охватывать:

– анализ прикладных программ и процедур целостности на предмет отсутствия нарушений после изменений операционной платформы:

– своевременное поступление уведомлений об изменениях, чтобы дать возможность перед их реализацией провести соответствующие тесты и анализы:

– внесение соответствующих изменений в планы обеспечения непрерывности бизнеса.

Операционные платформы включают в себя ОС, базы данных и межплатформенное ПО (взаимодействия системного и прикладного ПО).

Ограничение изменений пакетов программ

Меры и средства

Модификации программных пакетов должны не одобряться, а ограничиваться минимально необходимыми изменениями, и все изменения строго контролироваться.

Рекомендации по реализации

Насколько возможно, пакеты ПО, поддерживаемые поставщиком, должны использоваться без модификации. В случае необходимости модификации пакета программ, следует учитывать следующее:

– риск компрометации встроенных средств контроля и процедур целостности;

– необходимость получения согласия поставщика ПО;

– возможность получения требуемых изменений от поставщика в качестве стандартной программы обновления;

– последствия в случае, если организация в результате внесенных изменений станет ответственной за дальнейшее сопровождение ПО;

– совместимость с другим ПО при использовании.

При необходимости изменений их следует вносить в созданную копию ПО, а оригинальное ПО сохранить без изменений. Следует внедрить процесс управления обновлениями ПО, чтобы быть уверенным, что самые последние патчи и обновления приложений установлены во всем разрешенном ПО.

Все изменения должны быть полностью протестированы и задокументированы так, чтобы их можно было повторно использовать, при необходимости, для будущих обновлений ПО. Если требуется, модификации должны быть протестированы и утверждены независимым экспертом.

Разработка безопасных систем

Меры и средства

Принципы разработки безопасных систем должны быть установлены, задокументированы, поддерживаться и применяться при реализации ИС.