CC BY
120
Разработка нормативного подхода к управлению безопасностью сред облачных вычислений
Ключевые слова: публичные среды облачных вычислений, облачные вычисления, зарубежные стандарты обеспечения безопасности, NIST SP 800-53 Revision 4, CSA Security Guidance for Critical Areas of Focus in Cloud Computing V3.0, и ISO/IEC 270012013, NIST SP 800-144, NIST SP 800-145, NIST SP 800-146.
Анализ публикаций последних лет свидетельствует о том, что в области сред облачных вычислений (СОВ) ведётся активная работа с позиции стандартизации в зарубежном секторе, и несмотря на то, что имеющиеся стандарты и лучшие практики не в полной мере отражают особенности СОВ с точки зрения проработки деталей, применение этих документов может уже являться существенным при построении комплексного подхода к обеспечению безопасности. Среди подходов наравне с классическим выделяется тенденция управления СОВ путём управления сценариями (прецедентное управление), которые определяют один из вариантов использования и описывают типичный способ взаимодействия. Однако в документах отсутствуют конкретные рекомендации по управлению сценариями, в связи с чем, данная проблема является актуальной для проработки. Рассмотрены подходы к управлению безопасностью СОВ с нормативной точки зрения в контексте вектора функциональных возможностей сервиса СОВ или СОВ в целом. Это позволит эффективнее применять соответствующие стандарты и существующий в них набор требований в зависимости от конкретной СОВ.
Чемёркин Ю.С., [email protected]
Введение
Облачные вычисления (англ. cloud computing) представляют собой модель обеспечения повсеместного сетевого доступа по требованию к общему пулу конфигурируемых вычислительных ресурсов (например сетям передачи данных, серверам, устройствам хранения данных, приложениям и сервисам), которые могут быть оперативно предоставлены и освобождены с минимальными эксплуатационными затратами и/или обращениями к провайдеру.
Аспекты обеспечения безопасности СОВ находятся на начальном этапе развития, и проработаны в малой степени, так как ориентированы на решение вопросов управления безопасностью в отношении частных СОВ (а не публичных, либо в незначительной степени для публичных) со всей присущей им спецификой в контексте данной проблематики. Методы и средства не только отличаются по задачам, но и зачастую не применимы полностью или в достаточной мерс для поддержания приемлемого уровня безопасности СОВ. Более того, интеграция и внедрение новых механизмов защиты (публичных) СОВ на данном этане представляется технически сложным процессом, ввиду специфики самих публичных СОВ
В данной статье будут рассматриваться подходы к управлению безопасностью СОВ, принятые в зарубежных нормативных документах (далее стандартах) на предмет анализа степени применимости для современных решений типа СОВ, разработки методов, включающих методы определения принадлежности функциональности и методы оптимального выбора методологического подхода к обеспечению безопасности.
Подходы к стандартизации зарубежных доку ментов
в рамках управления безопасностью СОВ
При рассмотрении подходов к стандартизации зарубежных документов в рамках управления безопасностью
СОВ необходимо отметить, что ключевым термином является «информационная безопасность», а в случае СОВ
- «безопасность СОВ». Для рассмафиваемых документов NIST и CSA [1-7J термин определяется через конфиденциальность, целостность и доступность, а управление безопасностью СОВ как непрерывный процесс управления конфигурациями, наборами требований, рисками, изменениями и внедрениями решений. Представленные на даш1ый момент зарубежные стандарты можно разделить на три группы, содержащие:
1) универсальные рекомендации, которые могут быть использованы как базис для разработки требований в отношении каждой конкретной организации (сюда можно отнести 1SO/1FC 27001 в редакции 2013 г. [8], NIST SP 800-144 [7], NIST SP 800-145 [4] и NIST SP 800-146 [3];
2) функциональные требования обеспечения безопасности, направленные на техническую проработку набора требований обеспечения безопасности СОВ (сюда можно отнести NTST SP 800-53 в четвёртой редакции 2013 г. для СОВ [61);
3) «прецедентные» требования обеспечения безопасности, что является новым подходом к обеспечению управления безопасностью СОВ, однако представлено на данный момент в общем виде и в ряде случаев может быть рассмотрено как первая ipynna, содержащая универсальные требования (сюда можно отнести CSA Security Guidance for Critical Areas of Focus in Cloud Computing V3.0 L1-2J).
Положительной особенностью NIST SP 800-53 можно считать направленность на решение технических задач без организациошгых мероприятий, зависящих от процессов той или иной компании в целом. Это существенно отличает данный документ от прочих в связи с более детальной проработкой проблематики и возможностями детатизации требований обеспечения безопасности, а также полнотой и универсатьностью при применении в решении задач в рамках СОВ.
Сравнительные характеристики документов — NIST SP 800-53 Revision 4, ISO/IF.C 27001:2013, CSA Security Guidance for Critical Areas of Focus in Cloud Computing V3.0 — можно разделить следующим образом (табл. 1).
Таблица 1
Характеристики нормативной базы СОВ
Документ
Объект опенки
Плюсы
Минусы
< й «в >
U з
Lh Cl.
<8 є
<
ОТ'
U
Унификация рекомендаций для всех СОВ
Публикация представляє! собой су перетру ктуру в сравнении с другими
Унификация рекомендаций для всех СОВ
Требования безопасности покрывают базовые типы СОВ: SaaS, PaaS, laaS
Адашация происходи! пу i<5м публикации материалов от вендоров СОВ, заполненных с их стороны
Слабо учитывают специфику технических возможностей этих типов СОВ
Взаимосвязь с другими стандартами: PCI OSS, ISO, СОВТТ, NIST
Требования безопасности ориентированы на организационные в первую очередь
Множество допу щений особенно в части технических фебований безопасности (в частности, NIST);
Модель безопасности
Проработка требований на всех у ровнях в отношении типов СОВ
Противоречивы определённые роли и обязанности
конечных пользователей и вендоров СОВ
при выборе требований безопасности________________
Требования
(рекомендации)
Построение с использованием опыта женерюв к данной облает
Построение с использованием опыта экспертов в данной области
Некорректное экстраполирование частных примеров
Зависимость от устаревших данных
Большое количество ссылок на работы экспертов в рамках NL)A______________________________________
Новая структура требований (представляют собой преценден гные требования безопасности)______________________________
Различное понимание и интернрстация требований различными вендорами
и s
— гч
Модель безопасности
Новая редакция включает отраслевые требования
11абор отраслевых требований не акцентирован на конкретной отрасли (СОВ, мобильные устройства и т.п.)__________________________________________
Контекст управления требованиями сметён в сторону управления рисками
Внедрение SDLC лучшим образом применимо только к PaaS тину СОВ
Взаимосвязь с другими стандартами_____________
Внутренняя взаимосвязь (ISO/TF.C серия)
Отсутствуют внешние взаимосвязи
Модель безопасности
Ьдиная модель в рамках серии документов
Взаимосвязь с другими стандартами: ISO, Common Criteria, FIPS, серия NIST
Взаимосвязь двунаправленна
Слабые внешние взаимосвязи (ориентированность HaNIST серии)
Модель безопасности
Несколько у ровней расширения требований безопасности (повышение эффективности и гибкости)
Абстрагирование в ряде публикаций от отраслевых (специфичных) требований и необходимость само-стоятсльного выбора______________________________
Различные публикации отвечают конкретным целям — аудит, управления журналами событий, криминалистика, требования безопасности, облачная безопасность, мобильная безопасность и т.п.
Ряд публикаций, ссылающихся на публикацию SP 800-53 к\4, как набор фебований имеют допущения (недоработки)
Требования
(рекомендации)
Классическая структура групп и фебований (функциональное управление требованиями); несколько уровней детализации и расширения требований позволяют минимально применять специфичные региональные требования счандарюв_____________________________
Сложност ь управления с использованием ресурсного подхода к управлению безопасностью
Модели безопасности специальных публикаций (например, СОВ)
Содержаг общие сведения и очерченные наборы решаемых и нерешённых проблем
Среди нерешённых проблем стоит выбор требований безопасности, в том числе с учётом технических возможностей в отдельности для каждого СОВ
На сегодняшний день большинство стандартов, объединены в серии, такие как NIST или ISO/IEC, каждая из которых содержит большое количество взаимосвязей как внутри серий (внутренняя взаимосвязь), так и между (внешняя взаимосвязь). NIST SP S00-53 Revision 4, содержащий функциональные требования, определяет взаимосвязь с несколькими стандартами на уровне базовых требований (без их расширения и учёта зависимостей), такими как, ISO/IEC 27001:2005 [9], ISO/IEC 15408 [10]. С другой стороны, несколько других стандартов серии NIST (Л/ИТ SP 800-124 Revision /[II], NIST SP 800-144-146) содержат зависимости на требования, содержащиеся в документе NIST SP 800-53 Revision 4. Документы CSA определяют соответствие с большинством популярных документов (на данный момент старых редакций до 2012 г.).
Новые редакции опубликованных документов NTST,
ISO содержаг отсутствующие ранее требования безопасности, учитывающие специфику СОВ. В рамках этих документов была построена таблица [14] соответствий требований безопасности NIST SP 800-53 Revision 4 и ISO/IEC 27001:2013 с учётом зависимостей, 1SO/IEC 27001:2005 и ISO/IEC 27001:2013, так как текущие версии документов не отражают подобное соответствие, а также не могут учитывать специфику СОВ в таком случае. 11остроение соответствий между документами CSA и ISO/IEC 27001:2013, CSA и NIST SP 800-53 Revision 4 может осуществляться с использованием имеющихся таблиц соответствий между ISO/IEC 27001:2005 и /VAST SP 800-53 Revision 3 соответственно, а также построенной таблицы соответствий JSO/IEC 27001:2005 и 1SO/1EC 27001:2013 и таблицы отличий NISTSP 800-53 Revision 3 и NIST SP 800-53 Revision 4 доступной в новой версии документа NIST ввиду отсутствия сильных
противоречий между обновлёнными редакциями документов, что было практически проверено. При этом следует учитывать, что при использовании таблиц соответствия IVfST SP 800-53 с другими документами есть возможность обеспечить непротиворечивое соответствие только для базовых фсбований и их зависимостей, а соответствие требований между CSA и NIST SP 800-53 предполагает иной подход к управлению безопасностью, связанный с впервые введённым прецедентным управлением требованиями, а также нечёткие определения ролей и обязанностей пользователей СОВ и вендоров/провайдеров СОВ, что значительно усложняет применение этого документа. В случае, CSA была явно определена только одна пользовательская роль в отношении нескольких требований на организационном уровне, в то время как большинство из них определены как имеющие отношения к вендорам/провайдерам. При анализе материалов вендоров/провайдеров, представляющих собой заполненные документы па соответствие требованиям CSA, было экспериментально установлено различие в трактовках одних и тех же требований [13].
Формирование нормативного подхода
и модели безопасности СОВ
В рамках проведённого анализа возможно разработать подход к управлению нормативной базой (Compliance Management Approach). Рассмотрим более подробно. Подход подразумевает соответствие требованиям стандарта и его методологическому базису, что определяет вектор безопасности (дальнейшей разработки и проработки моделей и параметров безопасности соответственно для конкретных сервисов) и критерии безопасности СОВ (в рамках того или иного стандарта). В рамках проведённого ранее анализа были отмечены имеющиеся сильные и слабые стороны рассматриваемых публикаций. Акцентируем внимание на некоторых из них. В случае ISO/IEC 27001:2013 публикация ориентирована на управление рисками, что в ряде случае может быть недостаточно с технической точки зрения; также статус документа изменился на операционный и основная модель управления безопасностью связана с внедрением SDLC, что не предполагает детальной проработки требований как в случае NIST SP 800-53rev4. Несмотря на это, стандарт определяет множество типовых требований, которые в совокупности с механизмом профилей зашиты позволяют определять частные наборы требований.
В случае CSA публикация предлагает новый подход к управлению и разработана в расчёте на унификацию требований всех участников жизненного цикла от производителей до потребителей, где количественный фактор соответствия СОВ требованиям безопасности являет собой шкалу оценки безопасности. Однако, публикация предлагает слишком общие меры безопасности и имеет недостатки, связанные с нечеткой формулировкой принадлежности мер безопасности в отношении типов СОВ и обязанностей участников отношений в рамках выполняемых ими действий по принятию соответствующих мер безопасности. В случае NIST рассмафиваемая публикация ориен тирована исключительно на технические фебования безопасности, которые детально проработаны и имеют несколько фупп, чётко определяющих их предназначение, и несколько уровней расширения (улучшения) безопасности для повышения эффективности внедряемых требова-
ний. Аналогично ISO/1EC, документ также определяет множество требований, что вкупе с политиками безопасности позволяет конечным пользователям СОВ определять зависимые наборы требований в отношении сервисов, отвечающие конкретным сценариям. Несмотря на это, стоит проблема управления безопасностью СОВ, так как в специальной публикации, исключительно ориентированной на СОВ, вопрос управления и выбора фсбований безопасности отмечен как откры тый среди прочих.
Каждый из приведённых документов имеет таблицы соответствия фебований, однако добиться полного соответствия невозможно ввиду наличия уникальных для NIST SP 800-53 Revision 4 публикации фебований, отсутствующих в других документах, в связи с чем, они [таблицы] были определены только для базовых фебований и мер. Вопрос безопасности СОВ определяется по-разному в зависимости от документа. ISO/1EC ориентируется на описание угроз и нарушителей в дашюй среде, и исходя из этого определяет цели защиты ИС. CSA определяет уровень безопасности количественным показателем соответствия СОВ предъявляемым мерам. В случае NIST, уровень определяется уровнем приемлемого риска в зависимости от трёх классов ИС, каждая из которых считается слабо, средне и сильно подверженной риску. Уровень риска в свою очередь снижается путём применения соответствующих требований безопасности, выбор которых зависит от типа НС, например, мобильные устройства, СОВ, одно- или многопользовательские системы и т.п. При этом также учитывается применение расширенных фебований по безопасности, которые улучшают показатели ввиду их гибкости.
Решение задачи должно выполняться в рамках ранее сформированного нормативного подхода Compliance Management Approach, в рамках которого формируется модель безопасности (нормативная модель). Нормативная модель ставит целью конкретизацию вектора функциональности СОВ в общем смысле и объёма используемой функциональности из набора доступной в рамках СОВ. Рассмотрим подробнее. Конкретизация предполагает необходимость проведения работ, направленных па определение доступных функциональных возможностей СОВ или сервиса, выбора необходимого набора функциональности в рамках используемых сервисов. Это позволяет определить наиболее подходящий стандарт для управления СОВ в рамках конкретной функциональности. Это необходимо в таких случаях, когда один и тот же сервис СОВ может быть использован по разным целевым назначениям, так облачное виртуальное хранилище может быть использовано для размещения блога или в качестве обычного хранилища для пользователей, резервирования виртуальных СОВ, хранения БД при организации поиска с использованием сервисов СОВ и т.п. Так, например, упрощённый вариант хранения данных для пользователей может включать минимальный набор действий и политик безопасности на использование таких действий как создание, запись, чтение, удаление ресурсов, а также управление общими ресурсами, т.е. управление списком доступа пользователей (чтение, добавление пользователей, удаление пользователей). Более того, распространение информации через магазины (markets) СОВ фебует определить лишь подход к управлению списком, тогда как механизм лицензии сам применяет соответствующие политики безопасности.
Нормативная оценка определения
методологии безопасности СОВ
Вопрос выбора компонентов инфраструктуры СОВ определяет технологии и функциональные возможности, а также оказываемую степень их влияния и изменений в них на эффективность применяемых решений безопасности, что в целом позволяет лучше определить набор применяемых методов. Под функциональной возможностью СОВ в данной работе подразумеваются предоставляемые субъектам (пользователю, администратору, разработчику) возможности для взаимодействия с компонентами СОВ и информацией. Эти возможности допустимо выразить через набор АР1-функций, консольных команд доступных разработчику и пользователю (создание, удаление файла или реконфигурация параметров и т.д.). Каждая СОВ представлена набором функциональных возможностей, присущих только ей с одной стороны, но с другой стороны относится к тому или иному тину (модели Баа8, Раа8, Таа5), а в ряде случаев к нескольким сразу. Набор функциональных возможностей можно представить как сумму возможностей, где каждая из них имеет одинаковый вес, т.с. они являются равнозначными по отношению дру! к другу И
\С0’Ре\=^С/г (1)
/-0
где | С^уре| | — функциональные возможности типа СОВ (мощность), СI - /-я функциональная возможность данного типа СОВ
Аналогично, представим набор функциональных возможностей конкретной СОВ
п
I Сс1: 1=ЕС/-’ (2)
;=и
где |Сс/,| — функциональные возможности типа СОВ (мощность), С, - /-я функциональная возможность данного типа СОВ.
При этом установлено и экспериментально подтверждено соотношение между мощностью функциональных возможностей каждого типа СОВ из рассмотренных, которое можно выразить через
I СрааХ Н С&шЯ М С/оаХ N СЬуЬгШ 1> (’)
где — это мощность функциональных возможно-
стей СОВ типа Раа8, который имеет наименьшее количество доступных для использования возможностей, представляя собой окружения для разрабатываемых приложений, [Схаоз! — это мощность функциональных возможностей СОВ типа 8ааБ, который имеет большее количество доступных для использования возможностей, представляя конкретный сервис как блог или систему управления мобильными устройствами, |С/00я| — это мощность функциональных возможностей СОВ типа ТааЯ, который имеет наибольшее (среди перечисленных) количество доступных для использования возможностей, представляя собой инфраструктуру сервисов, каждый из которых также содержит некое количество функциональных возможностей, где (СдудгмI — это мощность всех функциональных возможностей СОВ, в случае, когда представляемый сервис (облако) предлагает все перечисленные типы СОВ. Далее последний тип (гибридный) в работе не
рассматривается как сводимый к частным случаям.
Очевидно, что функциональность СОВ отличается от типа СОВ как эталонной модели и варьируется в некотором диапазоне. Допустимо считать, что величина
одного типа СОВ, показывающая мощность множества функциональных возможностей конкретного СОВ, может варьироваться в пределах от Clv/X, | этого же типа СОВ, до |С№|: того же типа СОВ.
VCw-MCTHC^I2. (4)
Предполагая, что e&laS | =| CPaaS |2 , а
Vl ClaaS I Н CSaaS \2 > гДе ПрСДСЛЬНОС ЗНаЧСНИС | | В СОотношениях I К Vl Cpaas I и | |>| СIaaS |2 рассмат-
ривается как принадлежащее тем же типам СОВ - PaaS и IaaS соответственно. Очевидно, что соотношения
I с'у,№ I I С1у,к I
—ch <1 и . ch >1 являются индикатором принад-
\ClypL. ~ д/ ст№. |
I ptype I
лежностн СОВ к текущему типу СОВ, ———->1 - к
('tyfxs I
I С.'уре I
следующему типу СОВ, а . ch— < 1 — к предыдущему
yl С type
типу СОВ с учётом поправок на предельные значения.
В нашем случае действует предположение, что нам не требуется всё множество функциональных возможностей конкретного СОВ, поэтому необходимо ввести уточняющий коэффициент Kf= {0| 1}, принимающий два значения (0,1) соответственно, где 0 - индикатор отсутствия необходимости в использовании конкретной функциональной возможности Су, а 1 — наоборот. Такое СОВ здесь и далее называется кастомным СОВ. Таким образом, подставляя вместо I сТ значение |Ссш.,„я| формулы (4) могут быть переписаны в виде
_____ П
^<ZCA<|C-12 (5)
1=0
п
где ccmtim=Yj:fKfr о
Последняя формула справедлива также для случаев, когда один и тот же сервис СОВ может быть использован в зависимости от предполагаемого сценария, что влечёт за собой смену типа СОВ. Так, например, сервисы IaaS могут быть сокращены (функционально) и использованы для ведения блога, что по сути является SaaS типом СОВ.
Определение принадлежности кастомного СОВ по функциональности к типу СОВ позволяет в первом приближении выбирать подходящий нормативный документ для формирования требований в отношении этой СОВ. В случае необходимости их уточнения и смены набора требований выбранного документа, можно воспользоваться матрицами соответствия требований. В табл. 2 ниже представлена матрица 42 случаев соответствия модели СОВ, поставщика услуг СОВ и наиболее применимых международных стандартов в области управления безопасностью СОВ.
Таблица 2
Матрица соответствий СОВ и международных стандартов в области СОВ
Модель СОВ Вендор Международные стандарты
NIST ISO CSA
la aS Abiquo +
IaaS Amazon Web Services - - -
laaS AT&T -
IaaS Datapi pc + +
IaaS bnomaly +
laaS Eucalyptus -
IaaS riiel lost +
IaaS Go Grid + +
IaaS HP + +
IaaS Layered l ech +
laaS Logic works - -
IaaS Navisitc +
laaS Opsource +
IaaS Rackspacc 4 - +
IaaS Saw is +
PaaS Amazon Web Services - - -
PaaS Apprenda -
PaaS AppScalc 4-
PaaS Engine Yard
PaaS Gigaspaces -
PaaS Google + +
PaaS Openstack - -
PaaS OrangcScapc 4-
PaaS Salesforce.com + +
PaaS Visual WebGui - -
PaaS Windows Azure + +
RaaS Bluelock + +
SaaS Amazon Web Services + +
SaaS AppDynamics - -
SaaS BlackBcrry + +
SaaS С loud 9 - -
SaaS Cloudscaling + +
SaaS Datapi pe + +
SaaS Eloqua -
SaaS FinancialForce +
SaaS Intacct -
Saas MaaS360 by Fiberl ink + +
SaaS Market о -
SaaS Microsoft ()ffioe 365
SaaS Oracle On Demand -
SaaS Pardo L +
SaaS Salesforce.com + - +
Заключение
В ходе данной работы были решены следующие поставленные задачи:
- проведён анализ основных аспектов обеспечения и поддержания безопасности СОВ, особенностей современной зарубежной нормативной базы, отвечающей специфике СОВ;
- проведён анализ особенностей каждого из документов, позволяющий обозначить границы применимости требований в той или иной степени для различных типов СОВ;
- разработаны подходы к управлению нормативной базой, функциональными возможностями публичных СОВ и общий подход к управлению безопасностью СОВ;
На основании получеппых результатов были сделаны следующие выводы:
- об отсутствии в зарубежных стандартах методик управления безопасностью СОВ в условиях изменяющейся инфраструктуры для поддержания необходимого уровня безопасности СОВ и, как следствие, необходимости разработки моделей, позволяющих учитывать особенности различных СОВ при реализации требований в условиях отвечающих динамике окружения СОВ;
- существующие подходы, лежащие в основе зарубежных стандартов, могут быть расширены без противоречия оригинальным подходам с целью повышения эффективности управления безопасностью публичных СОВ.
В результате разработки нормативной модели могут быть определены показатели, в той или иной степени, применимые к типу СОВ в зависимости от функциональных возможностей СОВ и выделены соответствия между конкретными провайдерами услуг и нормативными публикациями. Подобная нормативная модель также учитывает все упомянутые ранее зависимости в соответствии с нотацией нормативных документов, которые определяют выбор требований безопасности.
Литература
1. “CSA Consensus Assessments Initiative Questionnaire vl.3” [Электронный ресурс]. Режим доступа: https://cloudsecurityalliance.org/research/cai/ (дата обращения 22.12.2012).
2. “CSA Cloud Controls Matrix vl.3” [Электронный
ресурс]. Режим доступа: https://cloudsccurityalliancc.org/
research/cai/ (дата обращения 22.01.2013)
3. “NIST Cloud Computing Synopsis and Recommendations.
SP 800-146”, [Электронный ресурс]. Режим доступа: http://csrc.nist.gov/publications/nistpubs/800-146/sp800-146.pdf (лата обращения 23.01.2013).
4. “NIST Definition of Cloud Computing. SP 800-145”, [Электронный ресурс]. Режим доступа: http://csrc.nist.gov/ publications/nistpubs/800-145/SP800-145.pdf (дата обращения 13.09.2013).
5. “NIST Guide for Assessing the Security Controls in Fed-
eral Information Systems and Organizations”, [Электронный ресурс]. Режим доступа: Building Effective Security Assessment Plans. SP 800-53 A Rev. 1”, [Электронный ресурс]. Режим доступа: http://csrc.nist.gov/publications/nistpubs/800-53A-rev I
sp800-53A-revl-final.pdf (дата обращения 11.12.2013).
6. “NIST Security and Privacy Controls for Federal Infonna-tion Systems and Organizations. SP 800-53 Rev. 4”, [Электронный ресурс]. Режим доступа: http://csrc.nist.gov/publications/nistpubs/ 800-53-rev4/sp800_53_r4_final_word_errata_01_l 5_2014.docx (дата обращения 10.12.2013).
7. “Guidelines on Security and Privacy in Public Cloud Computing”, [Электронный ресурс]. Режим доступа: csrc.nist.gov/publications/nistpubs/800-l 44/SP800-144.pdf (дата обращения 04.02.2013).
8. “Information technology - Security techniques - Information security management systems - Requirements. ISO/1EC 27001:2013”, [Электронный ресурс]. Режим доступа: http://www.iso.org/iso/eatalogue_detail?c.snumber=54534 (дата обращения 10.12.2013).
9. “Information technology Security tcchniqucs Information security management systems - Requirements ISO/IEC 27001:2005”, [Электронный ресурс]. Режим доступа: www.iso.org/iso/cataloguc_dctail?csnumbci=42103 (дата обращения 10.12.2013).
10. “Information technology — Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model, [Электронный ресурс]. Режим доступа: http://www.iso.org/iso/ iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=50 341 (дата обращения 10.12.2013).
11. “NIST Guidelines for Managing the Security of Mobile Devices in the Enterprise. SP-800-124 Rev. 1”, [Электронный ресурс].
Режим доступа: http://nvlpubs.nist.gov/nistpubs/ SpccialPublications/ NI ST.SP.800-124rl .pdf (дата обращен ия 15.04.2013).
12. У Chemerkin, “Limitations of Security Standards Against Public Clouds”, Proceedings of the International Confcrcncc on Information Society (i-Society 2013), Июль, 2013.
13. V Chemerkin, “Security compliance challenges on clouds”,Cyber Times International Journal of Technology & Management 2013, Vol. 6 Issue-1, ISSN No: 2278-7518, Март 2013.
" 14. “Remapping NIST 800-53 rev4: ISCMEC 27001:2013”, [Электронный ресурс]. Режим доступа: http://sto-stratcgy.com/ compliance/2014/3/19/remapping-nist-800-53-rev4-isoiec-270012013 (дата обращения 15.04.2013).
Compliance public cloud security management approach design Yury S. Chemerkin, [email protected]
Abstract
Nowadays, a cloud computing standardization is a popular topic for discussion in many countries from different viewpoints. The standard publications and best practices provide us with a least security that usually is dumped with descriptive generalizations and properties. The further research shows the lack of use cases depending on cloud features. This research examines different approaches on cloud security management from two key viewpoints - compliance and functionality. It provides an opportunity to raise the efficiency of given cloud control models and define the scope of an application depending on certain cloud models (laaS, PaaS, and SaaS).
Keywords: public clouds, cloud computing, international security management publications, NIST SP 800-53 Revision 4, CSA Security Guidance for Critical Areas of Focus in Cloud Computing V3.0, u ISO/IEC 27001:2013, NIST SP 800-144, NIST SP 800-145, NIST SP 800-146.
Referenses
1. "CSA Consensus Assessments Initiative Questionnaire v1.3". https://cloudsecurityalliance.ong/research/cai.
2. "CSA Cloud Controls Matrix v1.3". https://cloudsecurityalliance.ong/research/cai.
3. "NIST Cloud Computing Synopsis and Recommendations. SP 800-146". http://csrc.nist.gov/publications/nistpubs/800-146/sp800-146.pdf.
4. "NIST Definition of Cloud Computing. SP 800-145". http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
5. "NIST Guide for Assessing the Security Controls in Fed-eral Information Systems and Organizations". Building Effective Security Assessment Plans. SP 800-53 A Rev. 1", http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
6. "NIST Security and Privacy Controls for Federal Informa-tion Systems and Organizations. SP 800-53 Rev. 4", http://csrc.nist.gov/publications/nistpubs/ 800-53-rev4/sp800_53_r4_final_word_errata_01_15_2014.docx
7. "Guidelines on Security and Privacy in Public Cloud Computing". csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf.
8. "Information technology - Security techniques — Informa-tion security management systems — Requirements. ISO/IEC 27001:2013". http://www.iso.org/iso/calalogue_detaifcsnumbeF54534.
9. "Information technology — Security techniques — Informa-tion security management systems — Requirements ISO/IEC 27001:2005". www.iso.org/iso/catalogue_delail?csnumber=42103?
10. "Information technology — Security techniques - Evalua-tion criteria for IT security —Part 1: Introduction and general model. http://www.iso.org/iso/ iso_catalogue/cata-logue_ics/catalogue_detail_ics.htm?csnumber=50341.
11. "NIST Guidelines for Managing the Security of Mobile Devices in the Enterprise. SP-800-124 Rev. 1". http://nvlpubs.nist.gov/nistpubs/ SpedalPublications/NIST.SP800-124r1.pdf.
12. Y Chemerkin, "Limitations of Security Standards Against Public Clouds", Proceedings of the International Conference on Information Society (i-Society 2013).
13. Y. Chemerkin, "Security compliance challenges on clouds",Cyber Times International Journal of Technology & Man-agement 2013, Vol. 6 Issue-1, ISSN No: 2278-7518.
14. "Remapping NIST 800-53 rev4: ISO/IEC 27001:2013". http://sto-strategy.com/ compliance/2014/3/19/remappingnist-800-53-rev4-isoiec-270012013.
