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