08. Свод правил СУИБ (ISO/IEC 27002-2013). Часть 4

9. Безопасность связи

Безопасность связи обеспечивают следующие мероприятия:
- управление сетевой безопасностью;
- передача информации.

9.1. Управление сетевой безопасностью

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

Управление сетевой безопасностью определяют следующие составляющие:
- сетевые меры защиты;
- безопасность сетевых сервисов;
- разделение в сетях.

Сетевые меры защиты

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

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

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

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

- соответствующее протоколирование и мониторинг должны применяться для записи и определения действий, связанных или имеющих значение для ИБ;

- управляющие действия должны тщательно координироваться для оптимизации сервиса и согласованного внедрения мер защиты в инфраструктуру обработки информации;

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

Безопасность сетевых сервисов

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

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

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

Сетевые сервисы включают обеспечение подключений, личные сетевые сервисы и сети платных услуг (англ. value added network, VON) и управленческие решения по сетевой безопасности, такие как сетевые экраны и системы обнаружения вторжения. Диапазон таких сервисов простирается от простого неуправляемого траффика до комплексных платных услуг.

Особенностями безопасности сетевых сервисов могут быть:

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

Разделение в сетях

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

Рекомендации по реализации: одним из методов управления безопасностью больших сетей является их разделение на разные сетевые домены.

Домены выбираются на базе доверенных уровней (например, домен публичного доступа, домен рабочего стола, домен сервера), среди объектов организации (например, кадры, финансы, маркетинг) и каких-то комбинаций (например, домен сервера, подключающийся к многим объектам организации). Для разделения также можно использовать разные физические сети и разные логические сети (например, виртуальные частные сети - англ. Virtual Private Network, VPN).

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

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

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

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

9.2. Передача информации

Цель: Поддерживать безопасность информации, передаваемой внутри организации и в любую стороннюю организацию.

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

Политики передачи информации

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

Рекомендации по реализации. При использовании средств связи для передачи информации процедуры и меры безопасности должны содержать следущие элементы:

- процедуры защиты передаваемой информации от перехвата, копирования, модификации, ложной маршрутизации и разрушения:

- процедуры обнаружения вредоносного ПО, которое может передаваться при использовании электронных коммуникаций, и процедуры защиты от него;

- процедуры защиты передаваемой чувствительной электронной информации в форме прикрепленного файла;

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

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

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

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

- контроль и ограничения использования средств коммуникаций, например, автоматической пересылки электронной почты на внешние адреса;

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

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

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

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

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

Соглашения о передаче информации

Меры и средства: соглашения должны обеспечить безопасную передачу бизнес-информации между организацией и сторонними организациями.

Рекомендация по реализации. Соглашения о передаче информации должны включать следующее:
- обязанности руководства по контролю и уведомлению о передаче, рассылке и получению информации;
- процедуры обеспечения отслеживаемости и неотказуемости;
- минимальные требования технических стандартов упаковки и передачи информации;
- эскроу соглашения (хранятся у третьего лица и вступают в силу только при выполнении определенного условия);
- стандарты идентификации курьера;
- обязанности и ответственности в случае инцидентов ИБ, таких как потери данных;
- использование согласованной системы маркировки чувствительной или критичной информации, обеспечивающей ее немедленное понимание и соответствующую защиту;
- технические стандарты записи и считывания информации и ПО;
- любые специальные меры защиты, требуемые для защиты чувствительных элементов, например, криптография;
- поддержка цепочки поставок транзитной информации;
- применимые уровни контроля доступа.

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

Электронный обмен сообщениями

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

Рекомендации по реализации. Необходимо учитывать следующие рекомендации ИБ:
- защита сообщений от несанкционированного доступа, модификации или отказа сервиса, соизмеримая со схемой классификации;
- обеспечение правильной адресации и транспортировки;
- надежность и доступность сервиса;
- законодательные требования, например, по использованию ЭЦП;
- получение одобрения до использования внешних общедоступных услуг, таких как мгновенный обмен сообщениями, социальные сети или разделение файлов;
- строгие уровни аутентификации доступа со стороны общедоступных сетей.

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

Соглашение о неразглашении

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

Рекомендации по реализации: соглашение о конфиденциальности или неразглашении (англ. Non-Disclosure Agreement, NDA) должно отражать требования защиты конфиденциальной информации с применением существующих правовых понятий. Организации следует заключать NDA как со своими сотрудниками, так и с представителями сторонних организаций. Его содержание должно учитывать тип сторонней организации и возможного доступа к конфиденциальной информации или ее обработки.

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

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

10. Покупка, разработка и сопровождение ИС

Покупка, разработка и сопровождение ИС определяют следующие составляющие:
- требования безопасности ИС;
- ИБ при разработке ИС;
- тестовые данные.

10.1. Требования безопасности ИС

Цель: Обеспечить, что ИБ является неотъемлемой частью ИС в течение всего жизненного цикла. Это также включает требования к ИС, которые предоставляют сервисы в общедоступных сетях.

Требования безопасности ИС определяют следующие составляющие:
- анализ требований ИБ;
- ИБ сервисов в общедоступных сетях;
- ИБ транзакций прикладных сервисов.

Анализ требований ИБ

Меры и средства: требования ИБ должны быть включены в требования для новых ИС или по усовершенствованию действующих ИС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по реализации. Необходимо, чтобы ИБ транзакций прикладных сервисов содержала следующее:
- использование электронных подписей каждым участником сделки;
- все аспекты сделки, т. е. обеспечение уверенности в том, что:
  • пароли всех пользователей проверены и действительны;
  • сделка остается конфиденциальной;
  • приватность всех участников сохраняется;
- каналы связи между всеми участниками зашифрованы;
- протоколы, используемые для связи между всеми участниками, защищены;
- детали сделки хранятся за пределами общедоступной среды, например, в хранилище внутренней сети организации, и не хранятся на носителе, доступном из Интернета;
- там, где используются услуги доверенного органа (например, с целью применения цифровых подписей или цифровых сертификатов), ИБ является встроенной и неотъемлемой частью всего процесса управления сертификатом/подписью от начала до конца.

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

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

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

ИБ при разработке ИС определяют следующие составляющие:
- политика ИБ при разработке;
- управление изменением ИС;
- анализ приложений после изменений ОП;
- ограничение изменений пакетов программ;
- разработка безопасных систем;
- безопасность среды разработки;
- аутсорсинг разработки;
- тестирование безопасности;
- приёмное тестирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по реализации: насколько возможно, пакеты ПО, поддерживаемые поставщиком, должны использоваться без модификации.

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по реализации: безопасная среда разработки включает людей, процессы и технологии, связанные с разработкой и интеграцией системы.

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

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

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

Меры и средства: организация должна руководить аутсорсингом разработки системы и мониторить его.

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

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

Меры и средства: тестирование функциональности безопасности должно осуществляться в течение ее разработки.

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

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

Приёмное тестирование

Меры и средства: программы приёмного тестирования и связанный с ним критерий должны быть установлены для новых ИС, их обновлений и новых версий.

Рекомендации по реализации: приёмное тестирование системы должно включать проверку выполнения требований ИБ и соблюдения правил разработки безопасных систем. Тестирование должно также проводиться на полученных компонентах и встроенных системах.

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

10.3. Тестовые данные

Цель: Обеспечить защиту данных, используемых при тестировании.

Защита тестовых данных

Меры и средства: тестовые данные должны тщательно подбираться, защищаться и контролироваться.

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

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

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

Свод правил управления ИБ (ISO/IEC 27002-2013). Часть 5 (окончание)

----------------------------------------------------------------------------------------------------

Книга | Автор | Статьи | Фильмы | Фото | Ссылки | Отзывы

Контакт | Студентам | Ветеранам | Астрология | Карта сайта



Рейтинг@Mail.ru Яндекс.Метрика