ГОСТ Р ИСО/МЭК 27034-1—2014
b
) процессов, таких как неадекватные процедуры тестирования, плохой менеджмент проектов,
недостаточное внимание к безопасности в течение процессов жизненного цикла, непредвиденное
взаимодействие между приложениями, пользователями и операторами, неадекватные процессы ме
неджмента изменений:
c) технологического контекста, такого как плохо выбранная технологическая инфраструктура или
продукты:
d) особенностей, таких как неадекватное проектирование, уязвимости, обусловленные взаимо
действиями в системе или ошибками в интерфейсах компонентов.
6.5.3 Угрозы приложениям
Угроза несет в себе возможность причинения ущерба критической информации в сфере действия
приложения и соответственно самой организации. Угрозы проистекают из:
a) среды приложений: регулятивного контекста, бизнес-контекста и технологического контекста:
b
) действующих субъектов.
6.5.4 Влияние приложений
Влияние определяется расходами, понесенными организацией в результате нарушения доступ
ности. целостности или конфиденциальности критических данных приложений.
6.5.5 Менеджмент риска
Менеджмент риска приложений — это процесс поддержания рисков безопасности приложений на
допустимых уровнях. Это достигается путем обработки рисков безопасности приложений, сочтенных
неприемлемыми, посредством применения к ним мер и средств контроля и управления.
Менеджмент риска представляет собой ключевую концепцию в информационной безопасности.
Согласно ИСО/МЭК 27005, «процесс менеджмента риска информационной безопасности может
применяться к организации в целом; любой отдельной части организации (например, отделу,
физической площадке, услуге), любой информационной системе, существующим, планируемым
или конкретным аспектам мер и средств контроля и управления (например, планированию
непрерывности бизнеса)».
Представленный в ИСО/МЭК 27005 процесс менеджмента риска информационной безопасности
состоит из установления контекста, оценки риска, обработки риска, принятия риска, коммуникации ри
ска, мониторинга и пересмотра риска.
Процесс менеджмента риска безопасности приложений должен использовать такие же элементы
с более точной детализацией и сферой действия, установленной для уровня приложений.
6.6 Расходы на безопасность
Расходы организации на реализацию, поддержку и проверку мер и средств контроля и управле
ния безопасностью должны минимизироваться до допустимого (или приемлемого) уровня после над
лежащего рассмотрения рисков и соответствующего влияния использования приложений. Расходы на
безопасность должны учитывать потенциальное влияние угроз и уязвимостей.
6.7 Целевая среда
Целевая среда состоит из бизнес-контекста, регулятивного и технологического контекстов, в ко
торых организация будет использовать приложение. Все угрозы, которые могут причинить ущерб при
ложению, проистекают из этой среды. По этой причине в начале проекта приложения следует четко
определить целевую среду приложения.
Для успешного и безопасного использования приложения необходимо соответствие технологиче
ского контекста организации требованиям целевой среды приложения. Когда приложение реализуется,
технологический контекст организации может потребовать новых продуктов и аппаратных средств, ко
торые могут влиять на безопасность других приложений и риски безопасности организации.
Поскольку риски организации, использующей приложения, проистекают из целевой среды прило
жения, то должны быть определены новые требования безопасности приложений для учета этих новых
рисков и выбора мер и средств контроля и управления, уменьшающих эти риски до допустимого (или
приемлемого) уровня. Эти меры и средства контроля и управления безопасностью могут быть введены в
процессы жизненного цикла приложений (например, в процесс приобретения или в процесс снятия с
эксплуатации), добавлены к исходному коду приложения или интегрированы куда-либо еще в жизнен
ном цикле приложения (см. 8.3.4), когда это будет необходимо организации.
9