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

Гребенников Вадим Викторович

– все аспекты сделки, т. е. обеспечение уверенности в том, что:

• пароли всех пользователей проверены и действительны;

• сделка остается конфиденциальной;

• приватность всех участников сохраняется;

– каналы связи между всеми участниками зашифрованы;

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

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

– там,

где используются услуги доверенного органа (например, с целью применения цифровых подписей или цифровых сертификатов), ИБ является встроенной и неотъемлемой частью всего процесса управления сертификатом/подписью от начала до конца.

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

10.2. ИБ при разработке ИС

Цель: Обеспечить разработку и внедрение ИБ в рамках жизненного цикла разработки ИС.

ИБ при разработке ИС определяют следующие составляющие:

– политика ИБ при разработке;

– управление изменением ИС;

– анализ приложений после изменений ОП;

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

ИБ при разработке ИС обеспечивают следующие меры:

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

– безопасность среды разработки;

– аутсорсинг разработки;

– тестирование безопасности;

– приёмное тестирование.

Политика ИБ при разработке

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

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

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

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

– безопасность среды разработки;

– руководство по безопасности жизненного цикла разработки ПО:

• безопасность методологии разработки ПО;

• правила написания безопасного кода для каждого используемого языка программирования;

– требования безопасности в фазе проектирования;

– контрольные точки безопасности на этапах проектирования;

– безопасные хранилища;

– безопасность контроля версии;

– требуемые знания по безопасности ПО;

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

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

стандарты невозможно изучить или не соответствуют лучшим практикам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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