Критерии оценки информационной безопасности

19.08.2020
Комментариев нет

13.6.1. Цель разработки

«Единые критерии безопасности информационных технологий» (Common Criteria for Information Technology Security Evaluation, далее просто «Единые критерии») являются результатом совместных усилий авторов «Европейских критериев безопасности информационных технологий», «Федеральных критериев безопасности информационных технологий» и «Канадских критериев безопасности компьютерных систем», направленных на объединение основных положений этих документов и создание единого международного стандарта безопасности информационных технологий. Работа над этим самым масштабным в истории стандартов информационной безопасности проектом началась в июне 1993 года с целью преодоления концептуальных и технических различий между указанными документами, их согласования и создания единого международного стандарта. Версия 2.1 этого стандарта утверждена Международной организацией по стандартизации (ISO) в 1999 в качестве международного стандарта информационной безопасности ISO/IEC 15408.

Первая версия «Единых критериев» была опубликована 31 января 1996 г. Разработчиками документа выступили Национальный институт стандартов и технологий и Агентство национальной безопасности США, а также соответствующие организации Великобритании, Канады, Франции и Нидерландов. Вторая версия вышла в мае 1998, причем она отличается от первоначальной довольно существенными исправлениями и дополнениями. Данный обзор базируется на версии 2.1, отличающейся незначительными исправлениями, сделанными в ходе утверждения стандарта в комитетах ISO.

«Единые критерии» сохраняют совместимость с существующими стандартами и развивают их путем введения новых концепций, соответствующих современному уровню развития информационных технологий и интеграции национальных информационных систем в единое мировое информационное пространство. Этот документ разработан на основе достижений многочисленных исследований в области безопасности информационных технологий 90-х годов и на результатах анализа опыта применения положенных в его основу стандартов. «Единые критерии» оперируют уже знакомым нам по Федеральным критериям понятием «продукт информационных технологий», или ИТ–продукт, и используют предложенную в них концепцию Профиля защиты.

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

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

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

Кроме того, производители могут использовать «Единые критерии» для определения границ своей ответственности, а также условий, которые необходимо выполнить для успешного прохождения квалификационного анализа и сертификации созданного ими продукта.

Эксперты по квалификации используют этот документ в качестве основных критериев определения соответствия средств защиты ИТ–продукта требованиям, предъявляемым к нему потребителями и угрозам, действующим в среде его эксплуатации. «Единые критерии» описывают только общую схему проведения квалификационного анализа и сертификации, но не регламентируют процедуру их осуществления. Вопросам методологии квалификационного анализа и сертификации посвящен отдельный документ – «Общая методология оценки безопасности информационных технологий».

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

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

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

Рис. 3.6. Основные понятия «Единых критериев»

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

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

  • Оценка на соответствие эталону (бывает текущая и «эталонная», в идеале проводятся обе);
  • Риск-менеджмент;
  • Экономическая целесообразность.

Разберем эти понятия подробнее.

Оценка состояния информационной безопасности на соответствие эталону

В качестве «эталона» обычно принимаются (в совокупности и отдельно):

  • требования национальных или международных стандартов в области ИБ (ГОСТ, NIST);
  • требования законодательства Российской Федерации в области ИБ;
  • отраслевые требования по обеспечению ИБ, отдельные для разных сфер деятельности;
  • а также требования нормативных, методических и организационно-распорядительных документов по обеспечению ИБ внутри компании.

Эти критерии могут дополняться по предварительной договоренности, например, если глава вашего отдела по ИБ видит рентабельность такого исследования в отношении определенного проблемного участка структуры или собирается использовать результаты для дальнейших модификаций уже существующих протоколов ИБ. Как раз в зависимости от заданного «эталона» эта оценка может быть системно-ориентированной или процессно-ориентированной. Оценка текущего состояния системы ИБ сравнивает выстроенную по уже существующему эталону «идеальную» модель требований ИБ с теми, что уже были реализованы в компании в виде текущих защитных мер. Ее результаты легко понять и увидеть определенные слабые места, только вот последующие рекомендации при такой проверке обычно сводятся к самоочевидным и решают проблему на уровне «донастроить SIEM систему под конкретные нужды», «настроить оповещения в консоли антивируса», «установить или обновить ПО определенного вида». Это весьма полезно, и без надежной технической базы нельзя в принципе говорить о защите компании, но такая оценка очень редко дает данные для решения проблем на фундаментальном уровне или возможности расти дальше в более системном и полном смысле, и скорее помогает в текущих, кратковременных и частных вопросах. «Эталонная» оценка ИБ сравнивает процессы управления (менеджмента) ИБ организации с теми, что были определены как эталонные. Здесь мы определяем степень соответствия таких процессов, как создание отдела и распределение обязанностей по обеспечению ИБ, создание единых протоколов о политике обеспечения ИБ в компании, о реагировании на возникающие инциденты (ссылка на статью про расследование инцидентов), об инструктаже сотрудников компании в вопросах, связанных с ИБ и прочем. Такая проверка позволяет не только спрогнозировать дальнейшее развитие таких процессов в компании, но и скорректировать направление и подходы на более эффективные. Здесь также следует напомнить о том, что слишком много компаний полагается только на антивирусы и подобные системы защиты информации, тогда как большинство инцидентов прошлых лет произошло по внутренним каналам предприятий — как по причине недостаточной осведомленности среди персонала об окружающих угрозах, так и по причине слабо выстроенных систем реагирования на, уже произошедшие инциденты (например, многие компании обращают внимание на события с опозданием и только в стандартное рабочее время — конечно, этим пользуется масса хакеров, направляя атаки ночью и в выходные). В большинстве случаев при оценке по эталону используют оба вида проверки. Это обусловлено тем, что если системы организации не настроены должным образом, то без этой базы невозможно продвигаться дальше. Это фактически отсутствие защиты на нормальном уровне и провал оценки «защиты» сразу же, к тому же нет возможности опираться и доверять системам при построении руководства по обнаружению и реагированию на события и инциденты и, следовательно, единственная возможность эффективно двигать процессы на новый уровень — это опираться на хорошо работающие системы. Необходимость системно-ориентированной проверки лежит на поверхности, однако ее «базисность» не должна вводить в заблуждение, это не синоним «достаточности». Только с помощью эффективных и постоянно эволюционирующих процессов управления ИБ компании возможно придти к моменту, когда:

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

Оценка по эталону — это тот самый вид оценки, что проверяет эффективность вашей текущей защиты, превращает в количественную или качественную оценку процессы и систему, позволяет понять, насколько крепки ваши «стены» и что следует сделать для их укрепления.

Риск-менеджмент

Эта оценка рассматривает риски ИБ, возникающие в сфере конкретной организации и что было сделано для минимизации возможности возникновения, обработки/управления в целом. Для этого сначала определяют риски и их ключевые индикаторы, формируют на их основе критерии оценки, собирают свидетельства процессов по подготовке к встрече с рисками или результаты непосредственного инцидента, и, после измерения риск-факторов, формируется финальная оценка. Обычно риски измеряют по тяжести возможных последствий (ущербу) и по вероятности реализации угрозы. Соответственно, процессы контроля и реагирования заключаются в снижении либо эффекта, либо вероятности реализации риска. Большинство стен можно проломить тем или иным способом, но если затраты времени, усилий и прочих ресурсов значительно превышают возможную выгоду, то вероятность что кто-то будет этим заниматься, да еще и успеет сделать до подключения команды реагирования, крайне мала. Еще меньше вероятность того, что хакер сочтет это стоящим постоянного риска разоблачения и, во многих странах, уголовной ответственности. Одна из основных проблем такой оценки — это сложность понимания какие именно вещи могут привести к тяжким и дорогостоящим последствиям, а какие нет. В документации NIST приводится возможное прогнозирование ежегодных потерь с помощью определения информационного актива, фактора подверженности воздействию и ежегодной частоте появления, но даже данные этого уравнения достаточно размыты и могут предложить скорее некие рамки, чем реальные точные цифры. К тому же, как верно указано в ГОСТ Р ИСО/МЭК ТО 18044-2007, «незначительный инцидент ИБ может перейти в категорию «существенный» или в «кризисную ситуацию» в случае его неправильной обработки, или незначительный инцидент ИБ, не обработанный в течение недели, может стать «значительным» инцидентом ИБ.» Как раз потому, что собственные процессы компании могут стать разрушительными, а еще потому, что реагирование и контроль рисков можно проверить экспериментальным путем, в основном риск-ориентированная оценка направлена на анализ того, как менеджмент предприятия действует в отношении рисков — как оценивает, какими способами контролирует и реагирует, в отличие от простого перечня и классификации возможных рисков в вакууме. Такая проверка в меньшей степени тестирует «стены», это скорее прогнозирование потенциальных угроз и анализ действий защитников.

Экономическая целесообразность

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

Самостоятельное или независимое оценивание?

Самооценка уровня ИБ предприятия возможна, и во многих местах даже необходима — после введения нового процесса или модификации старого, после определенной настройки систем защиты или полученных новых знаний сотрудников, все это надо постоянно и неотступно тестировать, улучшать, развиваться через итерацию и проанализировать успех того или иного действия возможно только при проведении того или иного оценивания. Конечно, для подобных мелких процессов заполнять громоздкие формы стандартов NIST кажется излишним, и, хотя модель оценки процесса с десятками показателей сделает возможным более глубокий анализ, для большинства задач вполне можно сфокусировать усилия на ключевых 5-10 показателях оценки. Самое главное в такой самооценке — не потерять организованность оценивания. Здесь по-прежнему нужно еще до начала определить вид оценивания и критерии, нужно тщательно документировать собранные данные и их последующий анализ, сложные модели могут заменяться упрощенными, но все еще желательно преобразовывать процессы и системы в понятные графики и отчеты, к которым после можно получить доступ. Такие архивы могут помочь и самой компании наблюдать свое развитие или обращаться к данным в похожих ситуациях, а также могут стать отличным подспорьем для независимых экспертов в понимании подходов в вашей компании, с чем вы сталкивались ранее, и даже особенности ИБ для вашего бизнеса. Оценка от сторонних организаций или экспертов редко проводится для ежедневных нужд или мелких изменений — обычно более объективный взгляд со стороны нужен когда компания прошла длительный (месяц-два) цикл видоизменений своей ИБ и теперь нужен крупный аудит (как частный случай независимой оценки), чтобы увидеть, как именно все изменилось и правильно ли выбрано направление движения. Также помощь сторонних организаций для оценки требуется в следующих случаях:

  • Поиск новых методик и знаний. У ваших специалистов может быть ограничена квалификация и они оказались в тупике. Или стоимость некоторых процессов ИБ кажется неподъемной и оптимизация продвигается очень медленно. Независимый эксперт может поделиться современными технологиями и стандартами, рассказать где не надо переплачивать за оборудование, как можно построить в целом более стабильную систему, которая станет давать гораздо меньше нагрузки и на ваш бюджет, и на ваших спецов.
  • Оценка на соответствие государственным нормам и требованиям. Это как раз тот момент, когда большинство компаний заказывают комплексный аудит. Доверие выше к более объективной проверке от лицензиата со стороны, чем к самооценке предприятия. Более того, эксперты с нужной лицензией знают совершенно точно как соответствовать нормам государственной проверки и избежать штрафов, вплоть до заполнения всех необходимых форм.
  • Значительные изменения в компании или законодательстве. Новые законы, новое руководство, произошло слияние, расширился список услуг и поддерживающих их структур — в общем, так или иначе изменилась сама система защиты или требования к ее «эталону». В таком случае самооценка не представляется в полной мере возможной — это словно настройка самых первых дней, но только с участками старой архитектуры и для скорости преодоления «опасного» периода, а также отладки новых процессов управления ИБ необходим взгляд со стороны.
  • Критическая ситуация вне возможностей вашего отдела ИБ. При реагировании на инциденты всегда происходит проверка на контроль ситуации — и если вы вдруг оказались в той, что не поддается вашему контролю и реагированию, вам нужно срочно связаться со специалистами по безопасности сторонних организаций. Даже если они не успеют восстановить контроль до конца атаки, они смогут собрать информацию по преступлению для передачи ее в надлежащие органы, а также справиться с последствиями. Скорость и высокая квалификация в этом случае критичны, а потому если у вас есть подозрение на подобный инцидент, немедленно связывайтесь с экспертами по безопасности.

Я провожу независимое оценивание ИБ любого типа и сложности, возможны пентесты и приведение в соответствие по положениям 683-П, 684-П и ГОСТ 57580.1, ГОСТ 57580.2. Если вам нужна консультация по вопросам информационной безопасности, проведение независимой оценки вашей защиты, досудебные и судебные экспертизы по вопросам IT, а также экспертиза документации в этой области или разработка организационно распорядительной документации «с ноля» — оставляйте заявку в этой форме, они принимаются круглосуточно.

Автор статьи: Царев Евгений

Классификация функциональных требований безопасности

Часть 2 «Общих критериев», представляющая собой весьма обширную библиотеку функциональных требований безопасности, описывает 11 классов, 66 семейств, 135 компонентов и содержит сведения о том, какие цели безопасности могут быть достигнуты при современном уровне информационных технологий и каким образом.

Аналогия между библиотекой функциональных требований безопасности и библиотекой программных модулей является в данном случае довольно полной. Функциональные компоненты могут быть не до конца конкретизированы, поэтому фактические параметры подставляются не в самих «Общих критериях», а в определенных профилях защиты, заданиях по безопасности и функциональных пакетах. (Правда, в ГОСТ Р ИСО/МЭК 15408-2002 параметризация не очень удачно названа «назначением».) В качестве параметров могут выступать весьма сложные сущности, такие, например, как политика безопасности (ПБ).

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

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

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

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

К первой группе относятся следующие классы:

  • FAU — аудит безопасности (описывает требования к сервису протоколирования/аудита);
  • FIA — идентификация / аутентификация ;
  • FRU — использование ресурсов (прежде всего — обеспечение отказоустойчивости).

Классы второй группы:

  • FCO — связь (обслуживает неотказуемость отправителя/получателя);
  • FPR — приватность ;

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

  • FDP — защита данных пользователя;
  • FPT — защита функций безопасности объекта оценки.

Наиболее многочисленны классы, играющие инфраструктурную роль:

  • FCS — криптографическая поддержка (обслуживает управление криптографическими ключами и криптографические операции );
  • FMT — управление безопасностью ;
  • FTA — доступ к объекту оценки (управление сеансами работы пользователей);
  • FTP — доверенный маршрут / канал.

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

Во-вторых, в ОК не выделены архитектурные требования. Правда, некоторые весьма важные архитектурные компоненты, в числе которых — посредничество при обращениях (частный случай невозможности обхода защитных средств) и разделение доменов, вошли в класс FPT (защита функций безопасности).

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

Далее мы кратко рассмотрим все 11 классов функциональных требований безопасности «Общих критериев».

ОПРЕДЕЛЕНИЕ ПРОФИЛЯ ЗАЩИТЫ И ЗАДАНИЯ ПО БЕЗОПАСНОСТИ Грищенко Л.А.

Грищенко Лев Аркадьевич — магистрант, кафедра информатики и вычислительной техники, Новосибирский государственный технический университет, г. Новосибирск

Аннотация: в статье анализируются профили защиты, построенные на основе международного стандарта ISO/IEC 15408, описывающие сервисы безопасности, их комбинации и приложения. Выделяются общие требования, которые могут войти в состав функционального пакета, применимого ко всем сервисам, упрощающего разработку и понимание профилей для конкретных сервисов.

Ключевые слова: профиль защиты, информационная безопасность, ГОСТ Р ИСО/МЭК 15408, требования безопасности.

Профиль защиты (protection profile) — Независимая от реализации совокупность требований безопасности для некоторой категории изделий ИТ, отвечающая специфическим запросам потребителя . Профиль защиты — это специальный нормативный документ, представляющий собой совокупность задач защиты, функциональных требований безопасности (ФТБ), требований адекватности и их обоснование.

ГОСТ Р ИСО/МЭК 15408 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий» можно использовать в качестве руководства при разработке, оценке и/или приобретении продуктов информационных технологий с функциональными возможностями безопасности. В нем перечислен единый набор требований к функциональным возможностям безопасности продуктов информационных технологий и к мерам доверия, применяемым к этим продуктам информационных технологий при оценке характеристик безопасности.

ГОСТ Р ИСО/МЭК 15408 состоит из трех частей. Первая часть, «Введение и общая модель», устанавливает основные понятия и принципы оценки безопасности информационных технологий, а также определяет общую модель оценки, которой посвящены различные части стандарта, предназначенного в целом для использования в качестве основы при оценке характеристик безопасности продуктов информационных технологий.

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

Третья часть стандарта, «Компоненты доверия к безопасности», определяет требования доверия ИСО/МЭК 15408 и включает оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия для объекта оценки (ОО) компонентов, составные пакеты доверия (СоПД), определяющие шкалу для измерения доверия для составных ОО, отдельные компоненты доверия, из которых составлены уровни и пакеты доверия, а также критерии для оценки ПЗ и ЗБ.

В ГОСТе Р ИСО/МЭК 15408 определяются ключевые понятия профилей защиты (ПЗ), пакетов требований безопасности, а также рассматриваются вопросы, связанные с утверждениями о соответствии; описываются выводы и результаты оценки. Требования, представленные данном стандарте, используются при составлении профилей защиты, а также при последующем получении оценки доверия. Таким

образом, этот стандарт является одним из основных стандартов, применяемых для построения и разработки профилей защиты.

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

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

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

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

Для оценщиков в ИСО/МЭК 15408 содержатся критерии, которыми оценщики руководствуются при формировании заключения о соответствии объектов оценки предъявленным к ним требованиям безопасности.

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

• содержание файла или сервера;

• подлинность голосов, поданных на выборах;

• доступность процесса электронной коммерции;

• возможность использовать дорогостоящий принтер;

• доступ к средствам ограниченного доступа.

Среда, в которой размещаются эти активы, называется средой функционирования.

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

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

Среда функционирования также может содержать ошибки проектирования и реализации, что может привести к уязвимостям. Однако в ИСО/МЭК 15408 доверие не приобретается при рассмотрении корректности среды функционирования. Предполагается, что среда функционирования на 100% отражает цели безопасности для среды функционирования и ее не нужно оценивать.

Функциональные компоненты в ИСО/МЭК 15408-2 обычно имеют зависимости от других функциональных компонентов, также как некоторые компоненты доверия в ИСО/МЭК 15408-3 могут иметь зависимости от других компонентов ИСО/МЭК

15408-3. Могут быть также определены зависимости компонентов из ИСО/МЭК 15408-2 от компонентов из ИСО/МЭК 15408-3. Не исключено также наличие зависимостей расширенных функциональных компонентов от компонентов доверия или наоборот.

Согласно ИСО/МЭК 15408 необходимо, чтобы требования основывались на компонентах из ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3 с двумя исключениями:

• существуют цели безопасности для ОО, которые не могут быть преобразованы в ФТБ из ИСО/МЭК 15408-2, или существуют требования «третьей стороны» (например, законы, стандарты), которые не могут быть преобразованы в ТДБ из ИСО/МЭК 15408-3 (например, относящиеся к оценке криптографии);

• цели безопасности могут быть выражены на основе компонентов из ИСО/МЭК 15408-2 и/или ИСО/МЭК 15408-3, но только с большими трудностями и/или сложностями .

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

В обоих случаях от разработчика ПЗ/ЗБ требуется определить собственные компоненты. Эти вновь определенные компоненты называются расширенными компонентами. Точно определенный расширенный компонент необходим для обеспечения контекста и значения расширенных ФТБ или ТДБ, основанных на этом компоненте.

Для того, чтобы облегчить разработку заданий по безопасности и дать заинтересованным потребителям выражать свои потребности в безопасности в ГОСТ Р ИСО/МЭК 15408-1 определяются пакеты и профили защиты.

Согласно ГОСТ Р ИСО/МЭК 15408-1, профиль защиты — независимая от реализации совокупность требований безопасности для некоторой категории ОО, отвечающая специфическим запросам потребителя. Профиль защиты предназначен для описания типа ОО, а не какого-то конкретного ОО, как задание по безопасности. Поэтому один и тот же ПЗ может быть использован как шаблон для множества ЗБ, которые в свою очередь будут использоваться в различных оценках.

Профиль защиты описывает общие требования для типа ОО, поэтому его формирует не разработчик ОО (который обычно формирует ЗБ), а:

• сообществом пользователей, стремящихся прийти к консенсусу относительно требований для данного типа ОО;

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

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

В соответствии с ГОСТ Р ИСО/МЭК 15408, профиль защиты должен содержать следующие разделы:

• раздел «Введение ПЗ», содержащий описание типа ОО;

• раздел «Утверждения о соответствии», указывающий, утверждается ли в ПЗ о соответствии каким-либо ПЗ и/или пакетам, и если «да», то каким ПЗ и/или пакетам;

• раздел «Определение проблемы безопасности», в котором указываются угрозы, политика безопасности организации и предположения;

• раздел «Цели безопасности», показывающий, каким образом решение проблемы безопасности распределено между целями безопасности для ОО и целями безопасности для среды функционирования ОО;

• раздел «Определение расширенных компонентов» (опционально), в котором могут быть определены новые компоненты (т.е. компоненты, не содержащиеся в ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3). Эти новые компоненты необходимы,

чтобы определить расширенные функциональные требования и расширенные требования доверия;

• раздел «Требования безопасности», в котором цели безопасности для ОО преобразованы в изложение на стандартизованном языке. Этот стандартизированный язык представляет собой форму представления ФТБ.

Кроме того, в рассматриваемом разделе определяют ТДБ.

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

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

Рис. 1. Пример декомпозиции класса

ГОСТом Р ИСО/МЭК 15408 вводится уникальная краткая форма имени функционального элемента. Возьмем к примеру имя FAU_SAR.2.1. Оно читается следующим образом: F — функциональное требование, Аи — класс «Аудит безопасности», _SAR — семейство «Просмотр аудита безопасности», 2 (после точки) -второй компонент «Ограниченный просмотр аудита», 1 (после точки) — первый элемент компонента. То же самое обозначение применимо для ТДБ, только вместо F -функциональное требование, используется обозначение А — требование доверия к безопасности.

Список литературы

1. ГОСТ Р ИСО/МЭК 15408-1-2012. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. — Взамен ГОСТ Р ИСО/МЭК 15408-1-2008; Введ. 01 — 12 — 2013. Москва: Стандартинформ, 2014.

2. ГОСТ Р ИСО/МЭК 15408-2-2013. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности. — Взамен ГОСТ Р ИСО/МЭК 15408-2-2008; Введ. 01 — 09 — 2014. -Москва: Стандартинформ, 2014.

ОГРАНИЧЕННО ГОМОМОРФНЫЕ СХЕМЫ ШИФРОВАНИЯ

Якушкина А.А.

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

Аннотация: в статье представлен обзор известных ограниченно гомоморфных криптосистем. Обоснованы гомоморфные свойства рассмотренных криптосистем. Проведен сопоставительный анализ особенностей применения алгоритмов гомоморфного шифрования.

Ключевые слова: криптография, гомоморфное шифрование, облачные вычисления.

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

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

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

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

ОПРЕДЕЛЕНИЕ 1. Схема шифрования называется гомоморфной над операцией «?», если она поддерживает следующее уравнение:

Е(т{) ? Е(т2) = Е(т\ ? т2), Утьт2 6 М, (1)

где Е — алгоритм шифрования, а М — набор всех возможных сообщений.

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

12.1. Общая постановка задачи

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

В зависимости от целей исследования и этапов жизненного цикла ИС дефектологические свойства разделяют на дефектогенность, дефектабельность и дефектоскопичность.

Дефектогенность определяется влиянием следующих факторов:

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

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

  • структурно-конструктивные особенности ИС;
  • интенсивность и характеристики ошибок, приводящих к дефектам.

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

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

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

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

  • общая полезность;
  • исходная полезность;
  • удобство эксплуатации.

Далее формируются показатели, к числу которых могут быть отнесены:

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

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

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

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

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

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

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

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

Одним из путей обеспечения качества ИС является сертификация .В США Радиотехническая комиссия по аэронавтике в своем руководящем документе определяет процесс сертификации следующим образом:


Рис. 12.1. Модель классификации критериев качества информационных систем

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

В настоящее время не существует стандартов, полностью удовлетворяющих оценке качества ИС. В западноевропейских странах имеется ряд стандартов, определяющих основы сертификации программных систем. Стандарт Великобритании (BS750) описывает структурные построения программных систем, при соблюдении которых может быть получен документ, гарантирующий качество на государственном уровне. Имеется международный аналог указанного стандарта (ISO9000) и аналог для стран-членов НАТО (AQAP1). Существующая в нашей стране система нормативно-технических документов относит программное обеспечение к «продукции производственно-технического назначения», которая рассматривается как материальный объект. Однако программное обеспечение является скорее абстрактной нематериальной сферой. Существующие ГОСТы (например, ГОСТ 28195-89 «Оценка качества программных средств. Общие положения») явно устарели и являются неполными.

12.2. Стандарты управления качеством промышленной продукции

Международные стандарты серии ISO 9000 разработаны для управления качеством продукции, их дополняют стандарты серии ISO 14000, отражающие экологические требования к производству промышленной продукции. Хотя эти стандарты непосредственно не связаны с CALS- стандартами, их цели — совершенствование промышленного производства, повышение его эффективности — совпадают.

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

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

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

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

В стандартах ISO 9000 используется определение качества из стандарта ISO 8402: » Качество — совокупность характеристик продукта, относящихся к его способности удовлетворять установленные или предполагаемые потребности». Аналогичное определение содержится в ГОСТ 15467-79: » Качество продукции — это совокупность свойств продукции, обусловливающих ее пригодность удовлетворять определенные потребности в соответствии с ее назначением». В ISO 9000 вводится понятие системы качества (QS — Quality System), под которой понимают документальную систему с руководствами и описаниями процедур достижения качества. Другими словами, система качества есть совокупность организационной структуры, ответственности, процедур, процессов и ресурсов, обеспечивающая осуществление общего руководства качеством. Система качества обычно представляет собой совокупность трех слоев документов:

  • описание политики управления для каждого системного элемента;
  • описание процедур управления качеством (что, где, кем и когда должно быть сделано);
  • тесты, планы, инструкции и т. п.

Сертификация предприятий по стандартам ISO 9001-9003 выполняется некоторой уполномоченной внешней организацией. Наличие сертификата качества — одно из важных условий для успеха коммерческой деятельности предприятий.

Вторичные стандарты включают в себя:

  • ISO 9000 — основные понятия, руководство по применению ISO 9001;
  • ISO 9004 — элементы систем управления качеством. Поддерживающие стандарты предназначены для развития и установки систем качества:
  • ISO 10011 — аудит, критерии для аудита систем качества ;
  • ISO 10012 — требования для измерительного оборудования;
  • ISO 10013 — пособие для развития руководств по управлению качеством.

Часть этих стандартов утверждена как государственные стандарты Российской Федерации. В частности, к ним относятся:

  • ГОСТ Р ИСО 9001-96 «Системы качества. Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании»;
  • ГОСТ Р ИСО 9002-96 «Системы качества. Модель обеспечения качества при производстве, монтаже и обслуживании»;
  • ГОСТ Р ИСО 9003-96 «Системы качества. Модель обеспечения качества при окончательном контроле и испытаниях».

В настоящее время разработана новая версия стандартов серии ISO 9000 под названием ISO 9000:2000 Quality management systems (системы управления качеством ), в которую включены следующие документы:

  • ISO 9000:2000 Fundamentals and vocabulary (основы и терминология);
  • ISO 9001:2000 Requirements (требования);
  • ISO 9004:2000 Guidelines for performance improvement (руководство по развитию).

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

В стандарте ISO 9001 минимизируется объем требований к системе качества. Стандарты ISO 9002-9003 из новой версии исключаются. Расширяется круг контролируемых ресурсов, в их число включены такие элементы, как информация, коммуникации, инфраструктура.

Введенные в стандарте ISO 9004 двадцать элементов качества сворачиваются в четыре группы:

  • распределение ответственности (management responsibility);
  • управление ресурсами (resource management);
  • реализация продукции и услуг (product and/or service realization);
  • измерения и анализ (measurement, analysis, and improvement).

Сертификация предприятий по стандартам ISO 9001-9003 выполняется некоторой уполномоченной внешней организацией. Наличие сертификата качества — одно из важных условий для успеха коммерческой деятельности предприятий.

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

Контрольные вопросы

  1. Чем определяется качество ИС?
  2. Какие характеристики качества можно определить?
  3. Что определяет показатель качества?
  4. Охарактеризуйте дефектологические свойства в зависимости от целей исследования и этапов жизненного цикла ИС: дефектогенность, дефектабельность и дефектоскопичность.
  5. Как формируется показатель качества?
  6. Какие существуют виды метрических шкал для измерения критериев?
  7. Поясните модель классификации критериев качества информационных систем (рис. 12.1).
  8. Что оценивается с помощью функциональных критериев?
  9. Для чего предназначены конструктивные критерии?
  10. Расскажите о нормативных документах по оценке качества информационных систем.
  11. На чем традиционно основан контроль качества?
  12. Что является методической основой для управления качеством ИС?
  13. Что представляет собой совокупность документов системы качества?
  14. Что включают в себя вторичные стандарты системы качества?
  15. Для чего предназначены поддерживающие стандарты?