Управление информационной безопасностью. Стандарты СУИБ (СИ) - Гребенников Вадим Викторович - Страница 27

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

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

ИБ сервисов в общедоступных сетях

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

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

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

Необходимо, чтобы ИБ прикладных сервисов в общедоступных сетях содержала следующее:

– уровень доверия каждого участника требует от каждого другого участника удостоверения личности, например, с помощью аутентификации;

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

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

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

– уровень доверия к целостности ключевых документов;

– требования защиты любой конфиденциальной информации;

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

– степень проверки платежной информации, предоставленной заказчиком;

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

– уровень защиты конфиденциальности и целостности сведений о заказе;

– предотвращение потери или дублирования сведений о сделке;

– ответственность, связанная с любыми фиктивными сделками;

– страховые требования.

Многие их этих рекомендаций можно выполнить с помощью средств криптографии в соответствии с действующим законодательством.

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

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

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

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

ИБ транзакций сервисов

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

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

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

Необходимо, чтобы ИБ транзакций прикладных сервисов содержала следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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