УДК 681.3
В. А. Артамонов
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ СИСТЕМ УПРАВЛЕНИЯ КРИТИЧЕСКИ ВАЖНЫМИ ОБЪЕКТАМИ
Часть 2
Оценка безопасности АСУ ТП критической инфраструктуры
Рассматривая в предыдущем разделе нормотворческую деятельность уполномоченных органов (регуляторов) РФ в сфере ИБ АСУ ТП КВО подспудно возникал вопрос оценки этой самой безопасности. Чем руководствоваться разработчику, заказчику или аудитору таких сложных инфраструктур как КВО при оценке безопасности их автоматизированных систем на всех этапах жизненного цикла. Существует два подхода к проблеме оценки ИБ – это использование собственных национальных нормативных правовых методик и рекомендаций и использование мирового опыта на основе международных стандартов.
И надо же такому случиться, что во время работы над данной статьёй (февраль 2014г.) стал доступен общественности проект долгожданного нормативного документа ФСТЭК, подводящего итог нормотворческой деятельности «регуляторов» РФ:
«ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ ЗАЩИТЫ ИНФОРМАЦИИ В АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ УПРАВЛЕНИЯ ПРОИЗВОДСТВЕННЫМИ И ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ НА КРИТИЧЕСКИ ВАЖНЫХ ОБЪЕКТАХ, ПОТЕНЦИАЛЬНО ОПАСНЫХ ОБЪЕКТАХ, А ТАКЖЕ ОБЪЕКТАХ, ПРЕДСТАВЛЯЮЩИХ ПОВЫШЕННУЮ ОПАСНОСТЬ ДЛЯ ЖИЗНИ И ЗДОРОВЬЯ ЛЮДЕЙ И ДЛЯ ОКРУЖАЮЩЕЙ ПРИРОДНОЙ СРЕДЫ».
Несмотря на столь длинное своё название, данный документ лаконичен как боевой приказ, всеобъемлющ как армейский устав, прост и безотказен в работе как автомат Калашникова. Несомненно, после утверждения, он сыграет важную роль в ранжировании и сертификации российских АСУ ТП по уровням защищённости и аттестации КВО по соответствующим показателям. Но что делать с КВО сфера деятельности которых носит трансграничный характер, а соответствующие субъекты производственных отношений являются транснациональными корпорациями или находятся в юрисдикции субъектов международного права? Это трубопроводные системы всех уровней, ЛЭП, коммуникации, транспортные системы и т.п. На этот случай существуют международные стандарты по оценке безопасности, сертификации и аттестации подобных объектов, впрочем и не только таковых. Не будем загружать читателя опытом сертификации и аттестации продуктов и систем ИТ в развитых странах на предмет информационной безопасности в технологической сфере, скажем лишь о том факте, что в США существует как минимум четыре таких системы, из них две базируются на международных стандартах.
Давайте с этих позиций перейдём к анализу оценки защищённости базирующейся на международных стандартах. Базовым набором нормативных документов для анализа защищённости продуктов и систем ИТ является серия стандартов ISO/IEC 15408 [3,4,5], более известная в русскоязычной терминологии как «Общие критерии». К этой серии тесно примыкает стандарт ISO/IEC 18045 [6], более известный как «Методология оценки». Первая редакция этих стандартов датирована 1999 годом и по мере того как нарабатывалась практика применения этого «метастандарта», выпускались более поздние версии, последняя датирована 2008 годом. Вместе с тем следует заметить, что в РФ прямым введением выпущена серия стандартов аналогичного содержания, под общим титулом – «ГОСТ Р ИСО/МЭК 15408».
Международный стандарт ISO/IEC 15408 ориентирован в первую очередь на оценку продуктов информационных технологий. Среда, в которой функционируют или должны функционировать подобные продукты, специфицируется в общем виде, в форме предположений о среде. Действующие автоматизированные системы окружены вполне определенной, конкретной средой, которую можно и нужно учитывать в процессе оценивания безопасности.
Международный стандарт ISO/IEC 15408 ограничен рамками программно-технического уровня информационной безопасности. Для оценки продуктов информационных технологий этого, в принципе, достаточно; для систем АСУ ТП, проектируемых и находящихся в производственной эксплуатации, – нет. Международной организации по стандартизации (ISO) со стороны Российской Федерации было выдвинуто предложение разработать новый стандарт для оценки безопасности автоматизированных систем. Данная инициатива получила поддержку членов подкомитета 27 "Методы и средства обеспечения безопасности" (SC27) совместного Технического комитета 1 "Информационная технология" (JTC1), в результате появился технический доклад (технический проект) "Security assessment of operational systems" [7]. Учитывая сложившуюся в руководящих документах ФСТЭК России терминологию, предлагается переводить название этого проекта на русский язык как "Оценка безопасности автоматизированных систем".
Основная цель проекта 19791 – расширить международный стандарт ISO/IEC 15408 "Критерии оценки безопасности информационных технологий" (Evaluation Criteria for IT Security), чтобы сделать возможной оценку безопасности автоматизированных систем, находящихся в производственной эксплуатации или вновь проектируемых (модернизируемых). Подобное расширение необходимо, поскольку стандарт ISO/IEC 15408 в его нынешнем виде хотя и позволяет специфицировать программно-техническую функциональность безопасности как для продуктов, так и для систем информационных технологий , но не охватывает ряд критически важных аспектов действующих, эксплуатируемых автоматизированных систем (АС), точные спецификации которых необходимы для эффективного оценивания.
Проект содержит расширенные критерии оценки и рекомендации по оцениванию как программно-технических, так и административных и процедурных аспектов автоматизированных систем, в том числе SCADA-систем и АСУ ТП КВО. Применение комплексного подхода, охват мер всех уровней, направленных на обеспечение информационной безопасности, равно как и всех этапов жизненного цикла АС – еще одна цель проекта.
Проект ориентирован не только на оценщиков, но и на разработчиков, системных интеграторов и эксплуатационщиков АС, поскольку эти специалисты должны понимать, что требуется для получения положительной оценки безопасности АС.
Автоматизированные системы по своей природе сложны, они строятся из подсистем, часть из которых уникальны и являются результатом собственных разработок, другие же образованы типовыми продуктами общего назначения от различных производителей. Система в целом может строиться из подсистем системным интегратором, который не выполняет собственных разработок, обеспечивая лишь взаимосвязь и конфигурирование.
Автоматизированные системы взаимодействуют с другими системами и зависят от них. Как правило, автоматизированные системы обладают следующими свойствами:
- находятся под контролем одного владельца;
- строятся для достижения определенных целей и для функционирования в определенном режиме;
- подвержены частым изменениям, как в плане технического устройства, так и в плане эксплуатационных требований;
- состоят из значительного, порой очень большого числа компонентов;
- содержат покупные компоненты, в том числе продукты и системы ИТ с большим числом возможных вариантов конфигурирования;
- оставляют за владельцем выбор баланса между техническими и нетехническими мерами безопасности;
- содержат компоненты с различными уровнями и типами доверия к безопасности.
Оцениваемая автоматизированная система может взаимодействовать с другими АС и/или входить в состав более крупной системы. Системный объект оценки (СОО) включает в себя как технические средства, так и их эксплуатационную среду. Его граница пролегает там, где кончается непосредственный контроль системы. Все остальное рассматривается как внешняя АС.
У автоматизированной системы есть множество предоставляемых ею функций, внешние интерфейсы, а также внутренняя структура и внутренние интерфейсы. Каждый компонент может предоставлять одну или несколько функций и быть реализованным в виде одного или нескольких продуктов ИТ.
Автоматизированная система может состоять из нескольких доменов безопасности с различными функциональными требованиями и требованиями доверия к безопасности. Может быть определена общая политика безопасности АС, общие цели и требования безопасности, общая документация. В дополнение возможно существование аналогичного набора для каждого домена безопасности, содержащего специфическую для домена информацию.
В предлагаемом проекте принят трехзвенный подход к формированию режима безопасности автоматизированных систем.
Первый этап состоит в идентификации, анализе и оценке рисков, которым подвержена АС.
Второй этап – уменьшение (или ликвидация) рисков путем выбора, применения и оценки регуляторов безопасности. На третьем этапе проводится аккредитация АС, подтверждающая, что остаточные риски допустимы для системы, эксплуатируемой в конкретной реальной среде.
Процесс формирования режима безопасности АС изображён на Рис.2. В качестве средства достижения цели используется оценка безопасности, основанная на модели оценивания технических регуляторов, принятой в стандарте ISO/IEC 15408, но распространенная на регуляторы всех видов.
Рис.2. Процесс формирования режима безопасности АС
Несмотря на то, что оценивание рисков находится за рамками предлагаемого проекта, этот процесс должен быть документирован, так как его результаты являются исходными данными для разработки системного задания по безопасности.
Для формирования режима безопасности следует:
- идентифицировать риски, которые необходимо уменьшить или ликвидировать;
- сформулировать цели безопасности для технических, процедурных и административных регуляторов безопасности, призванных снизить все риски до приемлемого уровня;
- выбрать функциональные регуляторы, удовлетворяющие целям безопасности АС;
- определить конкретные, измеримые требования доверия для технических, процедурных и административных регуляторов безопасности, чтобы получить требуемую степень уверенности в способности автоматизированной системы достичь поставленных целей безопасности;
- зафиксировать принятые решения в системном задании по безопасности (СЗБ);
- оценить соответствие реальной автоматизированной системы системному ЗБ;
- периодически проводить переоценку рисков и способности АС этим рискам противостоять.
Регуляторы безопасности автоматизированной системы должны оцениваться на всем протяжении ее жизненного цикла. В рассматриваемом техническом докладе выделяются четыре этапа жизненного цикла:
- разработка/интеграция;
- ввод в эксплуатацию;
- производственная эксплуатация;
- сопровождение.
В качестве первого шага первого этапа указана идентификация рисков для автоматизированной системы. После того как выявлены недопустимо высокие риски, подлежащие уменьшению или ликвидации средствами безопасности АС, уполномоченное должностное лицо рассматривает ожидаемые остаточные риски и подтверждает их приемлемость.
Второй шаг – проектирование АС, включая определение используемых аппаратных и программных продуктов, поддерживающей инфраструктуры, прикладного программного обеспечения и необходимых технических регуляторов безопасности. Параллельно разрабатывается системное задание по безопасности, в которое включается описание системных требований безопасности, в том числе перечень рисков, которым необходимо противостоять, и целей безопасности, которых необходимо достичь с помощью технических, процедурных и административных регуляторов. Зафиксированный в СЗБ список регуляторов может рассматриваться как форма представления системных целей безопасности.
Уже на первом, самом раннем этапе жизненного цикла АС следует начинать проведение оценки ее безопасности. Это облегчит оценщикам понимание системы и ее предполагаемой эксплуатационной среды, анализ проектной документации и руководств, получение свидетельств доверия к безопасности. В идеале следует оценить все системное ЗБ, чтобы убедиться в отсутствии несоответствий и упущений в требованиях безопасности и предлагаемых регуляторах.
Третий шаг первого этапа – разработка или закупка базового и прикладного программного обеспечения, включая технические регуляторы безопасности, а также системная интеграция, конфигурирование и тестирование разработчиком/интегратором. Параллельно создается инфраструктура безопасности для административного и процедурного уровней, документируются политики, правила и процедуры безопасности, интегрируемые в системный контекст.
Если происходит перестройка существующей автоматизированной системы, то выполняется замена регуляторов безопасности в соответствии с изменившейся средой. Верификационная деятельность при этом должна быть увязана с масштабом и характером изменений.
За интеграционным тестированием разработчик выполняет тестирование безопасности, чтобы убедиться в выполнении предъявляемых системных требований. Обычно специфические для конкретной организации параметры безопасности (технические, административные и процедурные) могут быть определены до развертывания автоматизированной системы в производственной среде, поэтому разработчик/интегратор может выполнить верификацию регуляторов безопасности уже на первом этапе, до начала этапа ввода в эксплуатацию. Верификация должна подтвердить силу механизмов безопасности и корректность функционирования регуляторов.
Четвёртый шаг – оценка автоматизированной системы. Это даст владельцу АС независимое подтверждение того, что все риски, фигурирующие в СЗБ, благодаря применению регуляторов безопасности уменьшены до приемлемого уровня. В сертификационном докладе перечисляются все обнаруженные уязвимости и описываются рекомендуемые действия по их устранению. Владелец АС готовит план устранения недостатков. Результаты сертификации системы представляются уполномоченному должностному лицу, определяющему допустимость реальных остаточных рисков для системных активов и процесса функционирования.
Итог первого этапа – получение официального разрешения на ввод системы в эксплуатацию. На втором этапе система устанавливается, развертывается и готовится к использованию.
На этапе производственной эксплуатации выполняется протоколирование, непрерывное отслеживание работы технических, процедурных и административных регуляторов безопасности, обеспечивается обратная связь для корректирующих действий после внесения изменений в АС. Обычно осуществляется мониторинг не всех регуляторов, а только их критически важного подмножества. Кроме того, владелец системы должен располагать средствами управления конфигурацией, администрирования и аудита, которые позволяют получить текущую картину ресурсов АС и их конфигурации.
На этапе сопровождения рассматриваются и анализируются все предлагаемые или сделанные изменения АС, включая изменения политик, правил и процедур. При необходимости выполняется регрессионное тестирование. Если возможно значительное изменение остаточных рисков, то может потребоваться переоценка автоматизированной системы.
Сопровождение завершается выведением системы из эксплуатации, архивированием, ликвидацией или перемещением данных на другие системы. Уполномоченное должностное лицо должно заверить факт успешного завершения работы автоматизированной системы.
В проекте содержится описание семи новых, по сравнению со стандартом ISO/IEC 15408-2, классов функциональных требований, включающих следующие двадцать девять семейств:
- Класс FOD (администрирование, то есть действия руководства организации):
- FOD_POL(администрирование политик),
- FOD_PSN (администрирование персонала),
- FOD_RSM (администрирование управления рисками),
- FOD_INC (администрирование управления инцидентамибезопасности),
- FOD_ORG (администрирование организации безопасности),
- FOD_SER (администрирование сервисных соглашений);
- Класс FOS (системы ИТ):
- FOS_POL (политики для систем ИТ),
- FOS_CNF (конфигурирование систем ИТ),
- FOS_NET (сетевая безопасность систем ИТ),
- FOS_MON (мониторинг систем ИТ),
- FOS_PSN (управление персоналом систем ИТ),
- FOS_OAS (эксплуатационные активы систем ИТ),
- FOS_RCD (протоколирование для систем ИТ);
- Класс FOA (пользовательские активы):
- FOA_PRO (защита конфиденциальности данных),
- FOA_INF (защита информации в пользовательских активах);
- Класс FOB (производственная деятельность):
- FOB_POL(политики производственной деятельности),
- FOB_BCN (непрерывность производственной деятельности);
- Класс FOP (инфраструктура и оборудование):
- FOP_MOB (мобильное оборудование),
- FOP_RMM (съемное оборудование),
- FOP_RMT (удаленное оборудование),
- FOP_SYS (системное оборудование),
- FOP_MNG (управление инфраструктурой);
- Класс FOT (сторонние организации):
- FOT_COM (обязательства сторонних организаций),
- FOT_MNG (управление взаимодействием со сторонними организациями);
- Класс FOM (управление):
- FOM_PRM (управление параметрами безопасности),
- FOM_CLS (управление классификацией активов),
- FOM_PSN (управление должностными обязанностями, связанными с безопасностью),
- FOM_ORG (управление организацией безопасности),
- FOM_INC (управление докладами о событиях, связанных с безопасностью);
В предлагаемом проекте технического доклада, определены также десять новых по сравнению со стандартом ISO/IEC 15408-3 классов требований доверия, содержащих пятьдесят одно семейство:
- Класс ASP (оценка системного профиля защиты):
- ASP_INT (введение СПЗ),
- ASP_CCL (утверждения о соответствии),
- ASP_ECD (определение дополнительных требований безопасности),
- ASP_SPD(определение задачи безопасности),
- ASP_OBJ (цели безопасности),
- ASP_REQ (требования безопасности),
- ASP_DMI (введение для домена безопасности),
- ASP_DMC (утверждения о соответствии для домена безопасности),
- ASP_DMP (определение задачи безопасности для домена безопасности),
- ASP_DMO (цели безопасности для домена безопасности),
- ASP_DMR (требования для домена безопасности);
- Класс ASS (оценка системного задания по безопасности):
- ASS_INT (введение СЗБ),
- ASS_CCL (утверждения о соответствии),
- ASS_ECD (определение дополнительных требований безопасности),
- ASS_SPD (определение задачи безопасности),
- ASS_OBJ (цели безопасности),
- ASS_REQ (требования безопасности),
- ASS_TSS (краткая спецификация СОО),
- ASS_DMI (введение для домена безопасности),
- ASS_DMC (утверждения о соответствии для домена безопасности),
- ASS_DMP (определение задачи безопасности для домена безопасности),
- ASS_DMO (цели безопасности для домена безопасности),
- ASS_DMR (требования для домена безопасности);
- Класс AOD (руководства автоматизированной системы):
- AOD_OCD (определение конфигурации автоматизированной системы),
- AOD_ADM (руководство администратора автоматизированной системы),
- AOD_USR (руководство пользователя автоматизированной системы);
- Класс ASD (архитектурная, проектная и конфигурационная документация автоматизированной системы):
- ASD_SAD (архитектурный проект автоматизированной системы),
- ASD_IFS (функциональная спецификация интерфейсов автоматизированной системы),
- ASD_SSD (проект подсистем автоматизированной системы),
- ASD_CMP (проект неделимых компонентов автоматизированной системы),
- ASD_IMP (представление реализации),
- ASD_COM (концепция безопасности автоматизированной системы);
- Класс AOC (управление конфигурацией автоматизированной системы):
- AOC_OBM (базовая конфигурация автоматизированной системы),
- AOC_ECP (оцененные компонентные продукты),
- AOC_PPC (соответствие профилям защиты),
- AOC_NCP (неоцененные компонентные продукты);
- Класс AOT (тестирование автоматизированной системы):
- AOT_FUN (функциональное тестирование автоматизированной системы),
- AOT_COV (покрытие тестами автоматизированной системы),
- AOT_DPT (глубина тестирования автоматизированной системы),
- AOT_IND (независимое тестирование),
- AOT_REG (регрессионное тестирование);
- Класс AOV (анализ уязвимостей автоматизированной системы):
- AOV_MSU (неправильное применение автоматизированной системы),
- AOV_SOF (стойкость функций безопасности действующего СОО),
- AOV_VLA (анализ уязвимостей);
- Класс AOL (поддержка жизненного цикла автоматизированной системы):
- AOL_DVS (идентификация мер безопасности автоматизированной системы);
- Класс ASI (установка и поставка системной функциональности безопасности):
1. ASI_AWA (отработка навыков),
2. ASI_CMM (уведомление),
3. ASI_SIC (проверка производственной совместимости);
- Класс ASO (записи в автоматизированной системе):
- ASO_RCD (записи функционирования организационных регуляторов),
- ASO_VER (верификация организационных регуляторов),
- ASO_MON (мониторинг организационных регуляторов).
Между девятью новыми классами требований доверия к безопасности, определенными в предлагаемом проекте, и классами, описанными в стандарте ISO/IEC 15408-3, существуют очевидные параллели:
ASP является модификацией APE (оценка профиля защиты) для автоматизированных систем,
ASS – ASE (оценка задания по безопасности),
AOD – AGD (руководства),
ASD – ADV (разработка),
AOC – ACM (управление конфигурацией),
AOT – ATE (тестирование),
AOV – AVA (оценка уязвимостей),
AOL – ALC (поддержка жизненного цикла),
ASI – ADO (поставка и эксплуатация). И только класс ASO можно считать по-настоящему новым, не имеющим аналога в стандарте ISO/IEC 15408-3.
В соответствии с целью рассматриваемого проекта, новые требования доверия к безопасности охватывают весь жизненный цикл автоматизированных систем. На этапе разработки/интеграции применимы компоненты семейств AOL_DVS, ASD_IMP, ASD_SSD, ASD_CMP, ASD_IFS, ASD_SAD, ASD_COM, AOD_USR, AOD_ADM, AOD_OCD.
Этап ввода в эксплуатацию охватывается компонентами семейств AOC_OBM, AOC_ECP, AOC_PPC, AOC_NCP, AOT_FUN, AOT_COV, AOT_DPT, AOV_MSU, AOV_SOF, ASI_AWA, ASI_CMM, ASI_SIC, ASO_RCD, ASO_VER, AOT_IND.
На этапе производственной эксплуатации применимы компоненты семейств AOD_USR, AOD_ADM, AOD_OCD, AOC_OBM, AOC_ECP, AOC_PPC, AOC_NCP, AOV_MSU, ASI_AWA, ASI_CMM, ASI_SIC, ASO_RCD, ASO_VER, ASO_MON.
Наконец, этап сопровождения обслуживается компонентами семейств AOV_MSU, AOV_VLA и AOT_REG.
По традиции, идущей от стандарта ISO/IEC 15408-3, классы ASP и ASS стоят особняком, хотя требования класса ASS можно отнести к этапу разработки/интеграции. В предлагаемом проекте отсутствует какая-либо связь между новыми требованиями и определенными в стандарте ISO/IEC 15408-3 оценочными уровнями доверия.
По сравнению со стандартом ISO/IEC 15408-3 в предлагаемом проекте технического доклада имеются два отличия в форме описания требований доверия к безопасности.
Во-первых, элементы действий разработчика переименованы в элементы действий разработчика/интегратора, чтобы отразить тот факт, что автоматизированная система может строиться системным интегратором, отличным от разработчика компонентов и продуктов, использованных в АС, и оба они (и разработчик, и интегратор) могут сотрудничать при изготовлении и поставке необходимых свидетельств.
Во-вторых, в некоторых случаях за изготовление свидетельств отвечает руководство АС, поэтому в соответствующих семействах элементы действий по предоставлению свидетельств идентифицированы как действия руководителей.
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ СИСТЕМ УПРАВЛЕНИЯ КРИТИЧЕСКИ ВАЖНЫМИ ОБЪЕКТАМИ. ЧАСТЬ 1.
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ СИСТЕМ УПРАВЛЕНИЯ КРИТИЧЕСКИ ВАЖНЫМИ ОБЪЕКТАМИ. ЧАСТЬ 3.
Отправить статью в социальные сети, на печать, e-mail и в другие сервисы:
