Управление информационной безопасностью. Стандарты СУИБ (СИ) - Гребенников Вадим Викторович
Меры и средства
Организация должна руководить аутсорсингом разработки системы и мониторить его.
Рекомендации по реализации
Если осуществляется аутсорсинг разработки (привлечение для разработки сторонней организации), то по всей организационной внешней цепочке поставок необходимо учитывать следующее:
– лицензионные соглашения, собственность кода и права интеллектуальной собственности, связанные с аутсорсингом;
– договорные требования к безопасным методикам по созданию, кодированию и тестированию;
– предоставление внешнему разработчику применимой модели угроз;
– приемные испытания качества и точности результатов;
– предоставление доказательства применения порогов безопасности для минимизации применяемых уровней качества безопасности и приватности;
– предоставление доказательства достаточного тестирования на предмет отсутствия вредоносного ПО;
– предоставление доказательства достаточного тестирования на предмет наличия известных уязвимостей;
– эскроу соглашения (на случай отказа сторонней организации выполнять свои обязательства), например, если исходный код не длиннее имеющегося;
– договорное право на аудит мер защиты и процессов разработки;
– эффективная документация построенной среды, способствующая достижению результатов;
– ответственность организации за соблюдение действующих законов и проверку эффективности контроля.
Тестирование безопасности
Меры и средства
Тестирование функциональности безопасности должно осуществляться в течение ее разработки.
Рекомендации по реализации
Новые и обновляемые системы требуют всестороннего|тщательного| тестирования и проверки в течение|на| процессов разработки, включая подготовку|подготовка| детального плана|списка| действий и тестовых вводов и ожидаемых выводов|вывод| в пределах создаваемых условий|состояния|. Для внутренних|собственного| разработок такое тестирование должно изначально|первоначально, начально| выполняться|исполнить| группой разработчиков.
Независимое тестирование должно (и для внутренней|собственный|, и для аутсорсинговой разработки|разработки|) гарантировать, что|который| системные работы проведены именно так, как ожидалось. Степень тестирования должна соответствовать важности и типу|натуре, характеру| системы.
Приёмное тестирование
Меры и средства
Программы приёмного тестирования и связанный с ним критерий должны быть установлены для новых ИС, их обновлений и новых версий.
Рекомендации по реализации
Приёмное тестирование системы должно включать|включить| проверку выполнения требований ИБ и соблюдения правил|метод| разработки безопасных систем |разработки|. Тестирование должно также проводиться|вести| на полученных компонентах|элементе| и встроенных|интегрированных, комплексных| системах.
Организации|структура| могут усилить автоматизированные инструменты, например, применить анализаторы кодов или сканеры уязвимости, и должна проверить|верифицировать| исправление дефектов, связанных с безопасностью.
Тестирование системы нужно выполнять|исполнить| в реалистичной|реалистичной| испытательной среде, чтобы гарантировать, что|который| система не создаст уязвимостей для среды организации,|структуры| и что испытания были надежными.
10.3. Тестовые данные
Цель: Обеспечить защиту данных, используемых при тестировании.
Защита тестовых данных
Меры и средства
Тестовые данные должны тщательно подбираться, защищаться и контролироваться.
Рекомендации по реализации
Тестовые данные не должны содержать персональных данных и конфиденциальной информации. Если персональные данные или любая конфиденциальная информация необходима для тестирования, все чувствительные детали и содержание должны быть защищены удалением или модификацией.
Необходимо применять следующие принципы для защиты тестовых данных:
– процедуры разграничения доступа, применяемые в эксплуатируемых системах, должны применяться и в системах тестирования;
– должна быть отдельная авторизация на каждый случай копирования операционной информации в среду тестирования;
– после завершения тестирования всю операционную информацию следует немедленно удалить из среды тестирования;
– копирование и использование операционной информации должно протоколироваться для дальнейшего аудита.
Системное и приемное испытание, как правило, требуют значительных объемов тестовых данных, которые должны быть как можно более закрыты для попадания в них операционных данных.
11. Взаимоотношения с поставщиками
Взаимоотношения с поставщиками определяют следующие составляющие:
– ИБ в отношениях с поставщиками;
– управление оказанием услуг.
11.1. ИБ в отношениях с поставщиками
Цель: Обеспечить защиту активов организации, доступных поставщикам.
ИБ при взаимоотношении с поставщиками определяют следующие составляющие:
– политика ИБ в отношениях с поставщиками;
– включение ИБ в договор с поставщиками;
– ИКТ цепочки поставок.
Политика ИБ в отношениях с поставщиками
Меры и средства
Для уменьшения рисков, связанных с доступом поставщика к активам организации, должны быть согласованы с поставщиком и задокументированы требования ИБ.
Рекомендации по реализации
Организация должна в политике определить и обозначить меры ИБ конкретного доступа поставщика к информации организации. Эти меры предусматривают внедрение как организацией, так и поставщиком, процессов и процедур, включающих:
– определение и документирование типов поставщиков, например, ИТ сервисы, программы логистики, финансовые сервисы, компоненты ИТ инфраструктуры, которым организация предоставит доступ к своей информации;
– стандартный процесс и жизненный цикл управления отношениями с поставщиком;
– определение типов информационного доступа, который получат разные типы поставщиков, и мониторинг и контроль доступа;
– минимум требований ИБ к каждому типу информации и типу доступа в качестве базы для индивидуальных соглашений с поставщиком на основании бизнес-требований организации и их профиля риска;
– процессы и процедуры мониторинга соблюдения установленных требований ИБ для каждого типа поставщика и типа доступа, включая третью сторону анализа и проверки продукта;
– точность и полнота мер защиты, дающая гарантию целостности информации или ее обработки другим участником;
– типы обязательств, применимых к поставщикам для защиты информации организации;
– обработка инцидентов и непредвиденных обстоятельств, связанных с доступом поставщика, включая обязанности как организации, так и поставщиков;
– устойчивость и, при необходимости, восстановление и резервные механизмы обеспечения доступности информации или ее обработки другой стороной;
– обучение персонала организации, занимающегося покупками, применяемым политикам, процессам и процедурам;
– обучение персонала организации, взаимодействующего с персоналом поставщика, правилам сотрудничества и поведения с учетом типа поставщика и уровня его доступа к системам и информации организации;
– условия, при которых требования и меры ИБ должны быть прописаны в соглашении, подписываемом обеими сторонами;
– управление необходимыми перемещениями информации, средств ее обработки и т. п. и гарантия того, что ИБ обеспечивается на протяжении перемещения.
Информация может быть подвержена риску поставщиком при неадекватном управлении ИБ. Следует определить и применить меры защиты для администрирования доступа поставщика к средствам обработки информации. Например, если специально требуется конфиденциальность информации, то могут заключаться соглашения о неразглашении.
Другим примером являются риски защиты данных, если соглашение с поставщиком содержит передачу информации за пределы организации или удаленный доступ к ней. Организация должна быть уверена, что правовая или договорная ответственность за защиту информации остается в организации.
