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

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

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

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

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

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

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

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

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

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

— соответствующие внешние и внутренние|внутриконтурные| требования, например, правила или политики|полиса|;

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

— надежность персонала, работающего в среде разработки;

— степень|степень| аутсорсинга в разработке системы |разработкой|;

— необходимость разделения сред разных|другого| разработок |разработки|;

— контроль доступа к среде разработки |разработки|;

— мониторинг изменения|замены| среды и кода, хранящегося|запоминает, аккумулирует| там;

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

— контроль |контролируйте| движения данных из среды и в среду разработки.

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

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

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

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

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

Если осуществляется аутсорсинг разработки (привлечение для разработки сторонней организации), то по всей организационной внешней цепочке поставок необходимо учитывать следующее:

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

— договорные требования к безопасным методикам по созданию, кодированию и тестированию;

— предоставление внешнему разработчику применимой модели угроз;

— приемные испытания качества и точности результатов;

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

— предоставление доказательства достаточного тестирования на предмет отсутствия вредоносного ПО;

— предоставление доказательства достаточного тестирования на предмет наличия известных уязвимостей;

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

— договорное право на аудит мер защиты и процессов разработки;

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

— ответственность организации за соблюдение действующих законов и проверку эффективности контроля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Необходимо применять следующие принципы для защиты тестовых данных:

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

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

— после завершения тестирования всю операционную информацию следует немедленно удалить из среды тестирования;

— копирование и использование операционной информации должно протоколироваться для дальнейшего аудита.

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

11. Взаимоотношения с поставщиками

Взаимоотношения с поставщиками определяют следующие составляющие:

— ИБ в отношениях с поставщиками;

— управление оказанием услуг.

11.1. ИБ в отношениях с поставщиками

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

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

— политика ИБ в отношениях с поставщиками;

— включение ИБ в договор с поставщиками;

— ИКТ цепочки поставок.

Политика ИБ в отношениях с поставщиками

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

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

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

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

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

— стандартный процесс и жизненный цикл управления отношениями с поставщиком;

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

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

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

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

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

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

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

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

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

— условия, при которых требования и меры ИБ должны быть прописаны в соглашении, подписываемом обеими сторонами;

— управление необходимыми перемещениями информации, средств ее