Главная » Выпуски » Выпуск №11


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

Проблемы обеспечения непрерывности безопасности бизнеса на уровне АСУТП

Posted Ноябрь 5th, 2013 by admin

Баскаков А.В.
Начальник группы по ИБ ООО «ТЦ Комус»
Ведущий аудитор по стандарту ISO/IEC 27001:2005
выпускник группы CSO-01
Школы IT-менеджмента
РАНХиГС при Президенте РФ.
С ним можно связаться по e-mail: baskav@rbcmail.ru

1. Проблема обеспечения непрерывности безопасности бизнеса на уровне АСУТП
«Раньше люди нуждались в продуктах, чтобы выжить. Теперь продукты нуждаются в людях, чтобы выжить» - Николас Джонсон, американский юрист, профессор права, бывший глава Федеральной Коммуникационной Комиссии США.

В современном мире обеспечение непрерывности бизнеса выходит из плоскости вопросов корпоративной безопасности, распространяется еще и на промышленные автоматизированные системы (АСУ ТП). Основные компоненты и системы на производственных объектах, в том числе АСУ ТП, работают круглосуточно в режиме реального времени. От непрерывности функционирования этих систем зависит безопасность предприятия.

    • Актуальность обеспечения  безопасности на уровне АСУТП в современном мире

Согласно данным исследования вопросов безопасности промышленных систем от Positive Technologies [1], за период с 2005 года по 2012 год количество обнаруженных уязвимостей АСУ ТП с 1-й возросло до 98-ми. Такое увеличение количества уязвимостей объясняется тем, что безопасность АСУ ТП практически не рассматривалась, т.к. считалось, что эта изолированная среда, в которую попасть извне невозможно.  На самом деле это заблуждение, в современном мире после атак червя StuxNet, Duqu, Flame на системы АСУ ТП, стала очевидным возможность влияния на экономику страны за счет причинения вреда промышленным предприятиям.

По данным исследования SANS от февраля 2013 года [2] 40% респондентов заявили, что они были скомпрометированы или что они не знают, есть ли у них системы гарантированного обнаружения вторжений и система управления безопасности АСУТП. Остальные 60% респондентов вообще не знают, как ответить на вопрос о зафиксированных случаях несанкционированного проникновения в АСУ ТП или наличия системы управления, которая занимается вопросами управления безопасностью АСУ ТП.

Вместе с тем, по данным экспертов  The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) [3], в 2012 году зафиксировано 198 инцидентов направленных на АСУТП. В течение 12 месяцев, почти 10% респондентов обнаружили вторжение в АСУТП, а более 20 респондентов пострадали в трех или более инцидентах безопасности, связанных с АСУТП.

Основными последствиями реализации рисков информационной безопасности в результате несанкционированного управления АСУ ТП являются:

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

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

    • Практика обеспечения  непрерывности уровня АСУТП в мире

Хотя, сейчас существуют сотни ИТ-стандартов безопасности, лишь немногие из них являются полезными для обеспечения непрерывности АСУ ТП. Изначально, хорошо зарекомендовал себя стандарт под названием ANSI/ISA-99 «ISA-99 Security for Industrial Automation and Control Systems». В 2010 году этот стандарт был включен в список международных стандартов и получил код серии IEC 62443/ISA-99. По данным SANS наиболее часто используемым стандартом в области защиты АСУ ТП является NIST Guide to SCADA and Industrial Control Systems Security, который более известен как NIST SP800-82 «Guide to Industrial Control Systems» (40%) [4]. Другими часто используемыми документами по защите АСУ ТП являются рекомендации «20 Critical Security Controls» (34%) и сборник стандартов Североамериканской совета по надежности предприятий электроэнергетики NERC CIP (30%) [7].

Общий недостаток практики использования всех указанных выше стандартов АСУ ТП  является то, что они рассматривают особенности  обеспечения безопасности АСУ ТП (с учетом отличия от систем корпоративного уровня), но не учитывают необходимость подходить к обеспечению безопасности АСУ ТП, как к процессу управления, который должен обеспечить непрерывность бизнеса. В таком процессе должны быть такие обязательные элементы управления процессом, как  «владелец процесса», выделяемые «ресурсы», «выходы» процессов, «управляющие воздействия», «роли» ответственных и обратные связи, которые будут гарантировать совершенствование существующих процессов.

    • Ключевые  моменты в обеспечении непрерывности уровня АСУ ТП

Ключевыми особенностями в обеспечение информационной безопасности АСУ ТП в сравнении с корпоративными  автоматизированными системами является необходимость особого подхода, учитывающего существующую специфику АСУ ТП, а именно:

  • Требований к времени реакции системы – АСУ ТП предъявляют высокие требования к времени реакции системы и величине допустимого отклонения от него;
  • Требований доступности – на АСУ ТП налагаются требования по резервированию ключевых элементов архитектуры, без которых невозможно управление или аварийное завершение технологических процессов.
  • Функциональных и ресурсных ограничений – в  ряде случаев, лицензионные соглашения с разработчиками АСУ ТП и договоры о техническом сопровождении не допускают установку в АСУ ТП каких-либо внешних средств защиты информации без согласования с разработчиком АСУ ТП.
  • Особой расстановки приоритетов в обеспечении ИБ – для  АСУ ТП основным приоритетом является обеспечение достоверности и целостности информации о параметрах технологических процессов, обеспечение безопасности труда, промышленной и экологической безопасности, обеспечения работы в установленном режиме;
  • Требований к архитектуре безопасности – в  АСУ ТП оборудование, каналы связи и управляющая информация всех уровней, согласно многоуровневой модели управления, требуют равной степени защиты;
  • Эксплуатационных ограничениях – многие компоненты архитектуры АСУ ТП не имеют встроенных механизмов безопасности, таких как, например, шифрование, журналирование, аутентификация и т.п.
  • Управлении изменениями – обновления ПО (общесистемное, прикладное, firmware)  в АСУ ТП не всегда могут быть установлены сразу после их выпуска, поскольку они требуют проведения всестороннего тестирования как разработчиком АСУ ТП, так и конечным пользователем;
  • Условий  физического  взаимодействия – при  формировании требований к безопасности АСУ ТП необходимо учитывать характер физического взаимодействия компонентов АСУ ТП и физических сред и их взаимовлияние друг на друга.
  • Требований к коммуникациям –  в АСУ ТП широко используются аналоговые и цифровые сигналы ввода/вывода, передаваемые по слаботочным сетям.
  • Времени жизни компонентов системы – технологии, используемые в АСУ ТП, во многих случаях, разрабатываются для очень узкой и специфичной области, поэтому срок жизни таких технологий намного больше – в среднем от 10 до 15 лет.
  • Управлении технической поддержкой – техническая поддержка АСУ ТП обычно осуществляется одной или несколькими подрядными организациями, специализирующимися в области промышленной автоматизации;
  • Доступности компонентов системы – компоненты АСУ ТП могут быть физически изолированы и располагаться в удаленных и труднодоступных местах, в местах с агрессивными средами, в условиях высоких и низких температур, повышенной загазованности.

Вывод
Рассмотрев ситуацию со стандартизацией подхода к обеспечению безопасности АСУ ТП  можно сделать следующие выводы:

  • обеспечение безопасности важная проблема в области управления непрерывностью бизнеса. Обсуждаемый объект управления – АСУ ТП, это система реального времени и важно, чтобы  время реакции на инцидент приближалось к моменту появления инцидента. Возможные инциденты должны быть максимально идентифицированы, а контрмеры четко сформулированы, дежурный  персонал подготовлен к применению контрмер через обучение и регулярно проводимые учения;
  • в настоящее время в мировой практике не существует единого стандарта по решению проблемы безопасности на уровне АСУ ТП, на основе которого можно рекомендовать создание процесса управления безопасностью, единого подхода нет;
  • в существующих стандартах безопасности АСУ ТП вопросы управления процессом обеспечения безопасности либо не рассматриваются.  При этом все стандарты в большей степени ориентированы на технические меры по обеспечению безопасности. Без системы управления безопасности на уровне АСУ ТП говорить об управлении непрерывностью бизнеса организации невозможно.

­­2. Разработка адаптивной модели зрелости бизнеса при обеспечении непрерывности безопасности (Модель зрелости как инструмент развития процесса безопасности в организации)
«…Зрелость — это не годы, а состояние познания самого себя...» - Джон Ро́берт Фа́улз, английский писатель, романист и эссеист.
 Постановка задачи по внедрению и продвижению любого процесса управления в организации должна соответствовать уровню организационного и технологического развития, и в частности, процессов обеспечения безопасности.  Для определения стадии организационного и технологического развития организации и ее процессов в мировой практике существует понятие «модель зрелости». Модель зрелости используется как инструмент измерения состояния процесса на основе набора метрик, которые представляют собой определенные характеристики.

2.1. Обзор мировых практик по формированию моделей зрелости
Автор, изучил более 10 моделей зрелости и провел сравнение следующих моделей:

  • Open Information Security Management Maturity Model (O-ISM3) – разработана независимым консорциумом The Open Group;
  • Enterprise Information Management Maturity Model (EIM MM) – разработана Gartner, Inc;
  • NISTIR-7358 методология PRISMA – разработана National Institute of Standards and Technology;
  • Community Cyber Security Maturity Model (CCSMM) – разработана The Center for Infrastructure Assurance and Security  The University of Texas.

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

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

2.2. Разработка адаптивной модели зрелости
Ключевыми моментом при построении собственной модели зрелости процесса обеспечения непрерывности бизнеса является разделение метрик на два направления. Первое направление определяет обеспеченность условиями для внедрения процесса. Без определения состояния обеспеченности не имеет смысла говорить о развитии процесса обеспечения непрерывности бизнеса в дальнейшем, так как без наличия ряда метрик выстроить управляемый процесс невозможно. Второе направление определяет степень реализации подпроцессов при декомпозиции процесса обеспечения непрерывности бизнеса.

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

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

2.2.2 Характеристика атрибутов направления «Степень реализации подпроцессов» для адаптивной модели зрелости
Рассмотрим вторую часть модели зрелости, в которой будет оцениваться уровень зрелости процессов безопасности при декомпозиции функциональной модели. В модель зрелости входят следующие атрибуты:

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

2.4 Методика применения адаптивной модели зрелости
Оценка зрелости организации будет состоять из значений зрелости двух направлений. Производится оценка зрелости каждого из входящих в состав направления атрибутов, которым присваивается соответствующий уровень зрелости от 1 до 5. Оценка зрелости выбирается на основе зафиксированных данных. Далее общая оценка зрелости всего направления приравнивается к самой низкой оценке атрибутов (принцип «слабого звена»).   На основании полученной оценки, ответственному за процесс обеспечения непрерывности бизнеса следует планировать работы для повышения уровня зрелости сначала атрибутов с самыми низкими значениями (т.е. для поднятия уровня зрелости атрибута «Стратегия бизнеса» до уровня 2 путем разработки стратегии бизнеса), а затем повышение уровня зрелости всех остальных атрибутов к более высокому уровню. При планировании работ по повышению уровня зрелости максимальный шаг следует намечать на уровень на 2 значения выше текущего.

3. Функциональная модель процесса обеспечения непрерывности бизнеса
«Правило ведения войны заключается в том, чтобы не полагаться на то, что противник не придёт, а полагаться на то, с чем я могу его встретить; не полагаться на то, что он не нападет, а полагаться на то, что я сделаю нападение на себя невозможным для него.» - Сунь-Цзы — китайский стратег и мыслитель.

Обеспечение непрерывности бизнеса и как составляющую этого процесса непрерывность безопасности – это главная цель, которую ставит владелец бизнеса (бизнес-заказчик) перед менеджментом, в том числе управленцем по безопасности. Мы будем понимать, что обеспечение непрерывности есть главная задача роли Chief Security Officer (CSO), выполняя которую им будет достигаться поставленная цель. Поэтому, именно формулировка «обеспечение непрерывности бизнеса» будет ключевой в  именовании функциональной  модели.

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

    • Обеспечение информационной безопасности как составляющая часть непрерывности бизнеса

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

    • Проблема использования стандартов управления ИБ

Методологической основой для построения, поддержания и совершенствования  систем управления безопасности бизнеса являются международные стандарты. В этой роли в области управления информационной безопасностью выступают как международные стандарты (ISO/IEC 27001:2005, ISO/IEC 27002:2005, ISO/IEC 27005:2008), так и отраслевые стандарты (Стандарт Банка России СТО БР ИББС). Проблемы применения стандартов, основанных на цикле PDCA были освещены на Конференции РАНХи ГС «Инвестиции. Инновации. Информационные Технологии (Взгляд на ИТ через призму менеджмента)» [23]. Сделаны следующие выводы:

  • В практике международных  стандартов единого устоявшегося понятия “цикл PDCA” нет, оно постоянно эволюционирует;
  • Явного упоминания о цикле SDCA и его трактовке в качестве инструмента стабилизации (стандартизации) не используется ни в одном из указанных источников, а это – важнейший элемент при построении системы управления процессом (бизнес-процессом);
  • Цикл PDCA, используемый во всех приведённых стандартах, – высокоуровневое описание, базирующееся на процессном подходе, которые не содержат описания конкретных шагов по внедрению их рекомендаций;
  • Во всех рассмотренных документах в том или ином виде используется понятие “заинтересованные стороны” (Stakeholders). Однако это важнейшее понятие при практической реализации указанных стандартов – “заинтересованные стороны” не детализируется. Декомпозиция понятия “заинтересованные стороны” возможна с учетом архитектурного подхода. В этой связи, Принципы менеджмента качества, на которых базируются все другие стандарты, целесообразно модифицировать в соответствии с идеями, лежащими в основе стандарта ISO/IEC 15288:2008;
  • В основополагающем стандарте (ISO 9000:2000) среди восьми принципов менеджмента качества декларируется, что “Работники всех уровней составляют основу организации, и их полное вовлечение дает возможность организации с выгодой использовать их способности” (Вовлечение работников). Понятно, что работники, участвующие в процессе, лучше, чем кто-либо другой знают и понимают его (процесса) сильные и слабые стороны. Из данных, приведенных в анализируемых документах, не следует, как будет реализовываться данный принцип. И уж совсем не ясно с помощью какого механизма может быть реализован такой принцип как “Принятие решений, основанное на фактах”.

Сделанные выводы позволяют утверждать, что при использовании понятия цикла PDCA в международных стандартах, не используется понятие цикл SDCA, который является важным элементов оперативного управления

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

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

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

    • Функциональная модель “Обеспечение непрерывности безопасности бизнеса”

Будем использовать понятие функциональное моделирование основанной на методологии SADT [25]. Принципы моделирования представлены в РД IDEF0 [26] «вход (I) при наличии управления (C) преобразуется в выход (O) посредством (при помощи) механизма (исполнителя) (M)». Если при этом некоторый вход одновременно является и управляющими воздействиями, то в соответствии со стандартом IDEF0 он отображается только как управление.  Первая диаграмма описывает систему в целом и ее взаимодействие с окружающим миром, т.е. контекстная диаграмма основного процесса обеспечения непрерывности безопасности бизнеса. Все последующие диаграммы являются функциональными декомпозициями первой диаграммы, которые будут являться подпроцессами главного процесса. 
Общая схема модели процесса обеспечения непрерывности информационной безопасности в нотации IDEF0 представлена на рисунке 1 в диаграмме А-0.

Рис. 1. Общая схема процесса.
В композиционной диаграмме A-0 процесса представлены следующие составляющие:

  • входы (I) модели:
    • ресурсы, выделяемые владельцем бизнеса для управления процессом непрерывности безопасности бизнеса
    • инциденты, события, которые возникают во «внешнем относительно процесса мире», которые могут влиять на функционирование процесса;
  • выходы (O) модели:
    • первой частью выходов процесса являются проекты документов, утверждение которых должен осуществлять владелец бизнеса как постановщик задачи и владелец выделяемых ресурсов. Это утверждение сделано из того, что CSO не может нести ответственность за бизнес;
    • второй частью выходов являются результаты управления описываемым процессом «защищенный бизнес» и откорректированная «база данных «Инциденты»;
  • управляющие воздействия (C):
    • стратегия бизнеса – верхнеуровневый документ компании;
    • стандарты безопасности – международные и отечественные лучшие практики и отраслевые стандарты;
    • стратегия  безопасности бизнеса, политики безопасности бизнеса, угрозы и цели защиты, карта рисков – документы, которые были  разработаны в рамках процесса, и которые в обязательном порядке утверждены владельцем бизнеса;
    • база данных «Инциденты»;
  • исполнитель (М):
    • ответственным исполнителем за процесс является CSO, который назначается владельцем бизнеса.
    • Описание декомпозиции диаграммы A0 «Управлять непрерывностью безопасности бизнеса»

Декомпозиции процесса «Управлять непрерывностью безопасности бизнеса» представлена на диаграмме А0 (см. рис. 2) и будет состоять из следующих подпроцессов (блоки):

  • «Определять стратегию и политику безопасности бизнеса» (диаграмма А1);
  • «Определять угрозы, цели защиты, карту рисков» (диаграмма А2);
  • «Управлять механизмами контроля» (диаграмма А3);
  • «Регулировать обеспечение непрерывности безопасности бизнеса» (диаграмма А4).

Блоки А1, А2 и А3 выполняют роль целеполагания – стратегическое управление, блок А4 – оперативное управление.  Механизмы обратной связи:

  •  от блока  А4 к блоку А3 – «Статус отчет о регулировании»;
  • от блока А3 к блоку А2 – «Требование на пересмотр угроз»;
  • от блока А2 к блоку А1 – «Требование на пересмотр политик / стратегии».


Рис. 2. Декомпозиция диаграммы A0
«Управлять непрерывностью безопасности бизнеса»

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

    • Описание декомпозиции диаграммы A4 «Регулировать обеспечение непрерывности безопасности бизнеса»

Декомпозиция подпроцесса «Регулировать обеспечение непрерывности безопасности бизнеса»  представлена на диаграмме А4 (см. рис. 3) реализует оперативный цикл управления (SDCA). Этот блок при декомпозиции может быть представлен следующими подпроцессами (см. рис. 3):

  • «Контролировать, анализировать и вырабатывать управляющие воздействия» (А41);
  • «Развертывать процессы, реализующие механизмы контрмер» (А42);
  • «Выполнять процессы, реализующие механизмы контроля» (А43);
  • «Выполнять тестирование внешнего проникновения» (А44).

a4.JPG
Рис. 3. Декомпозиция диаграммы A4 подпроцесса
«Регулировать обеспечение непрерывности безопасности бизнеса»

    • Применимость функциональной модели к специфике АСУ ТП

Рассмотренная функциональная модель является инструментом управления процесса обеспечения непрерывности безопасности бизнеса и применима не только для автоматизированных систем корпоративного уровня, но и для автоматизированных систем управления технологическими процессами на производственных предприятиях. Поэтому в рамках данной работы разработанные положения будут применяться в дальнейшем для уровня АСУ ТП с учетом его специфики.

В частности основные замечания будут касаться технических мероприятий обеспечения безопасности. Так  в блоках «Развертывать процессы, реализующие механизмы контрмер» (А42), «Выполнять процессы, реализующие механизмы контроля» (А43) технические мероприятия перед внедрением в промышленную эксплуатацию должны проверяться на корректность функционирования на тестовом стенде, который эмулирует существующую АСУ ТП. А блок  «Выполнять тестирование внешнего проникновения» выполняется исключительно на тестовом стенде, который эмулирует существующую АСУ ТП, без тестирования на реально функционирующей АСУ ТП. Выполнение тестирования возможно только в случае остановки технологического процесса, который обслуживает АСУ ТП.

4. Проект стандарта обеспечения непрерывности безопасности на уровне АСУТП
Тот, кто хорошо подготовился к сражению, наполо­вину победил – Миге́ль де Серва́нтес Сааве́дра —испанский писатель. 
Была обоснована необходимость использования модели зрелости, как инструмента оценки состояния и определения дальнейшего развития процесса обеспечения непрерывности безопасности бизнеса, а также разработана адаптивная модель зрелости этого процесса.  Было обосновано необходимость использования функционального моделирования как методологическая основа управления процессом непрерывности безопасности бизнеса.
Эти  инструменты управления процессом в обязательном порядке должны войты в стандарт, так как предназначены для повышения эффективности управления и постоянного совершенствования процесса.

    • Общая структура проекта стандарта

Состав проекта стандарта должен содержать:

  • Общую характеристику объекта защиты, в котором должны быть описаны состав и особенности АСУ ТП. Это раздел должен быть в составе стандарта потому, что обеспечение безопасности АСУ ТП имеет ряд отличий от безопасности корпоративных систем управления;
  • Описание инструментов управления процесса безопасности, таких как модель зрелости и функциональная модель процесса. Указанные инструменты управления являются ключевыми положениями, которые должны гарантировать не только создание процесса обеспечения непрерывности безопасности, но и его постоянное функционирование и совершенствование. Без этого говорить о непрерывности безопасности бизнеса не возможно. В описание модели зрелости должно войти рассмотрение параметров оценки зрелости, методология применения этой модели, требование об определении текущего уровня зрения и определения дальнейших  шагов по повышению этого уровня. Функциональная модель процесса должна содержать описание подпроцессов процесса управления, распределения ответственности по соответствующим ролям;
  • Описание требований к мероприятиям защиты, которые содержат защитные механизмы согласно типовой архитектуре безопасности АСУ ТП на всех уровнях иерархической инфраструктуры.
    • Описание оглавления стандарта

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

  • Общая характеристика объекта защиты;
    • Область применения;
    • Источники разработки и нормативные ссылки;
    • Определения и сокращения
    • Цели стандарта
    • Характеристика объекта защиты
    • Модель угроз информационной безопасности АСУ ТП
    • Модель потенциального нарушителя ИБ
    • Типовая архитектура безопасности АСУ ТП
  • Требование к управлению процессом обеспечения непрерывность безопасности на уровне АСУ ТП
    • Модель зрелости
    • Требования к применению процессной модели управления ИБ АСУ ТП
    • Функциональная модель процесса обеспечения непрерывность безопасности на уровне АСУ ТП
  • Требования к мероприятиям защиты
    • Требования по контролю физического доступа к АСУ ТП и защите от воздействия окружающей среды
    • Требования информационной безопасности к составу, функционалу и конфигурированию ПО АСУ ТП
    • Требования по защите АСУ ТП от несанкционированного доступа
    • Требования по обеспечению ИБ сетевой инфраструктуры АСУ ТП
    • Требования по обеспечению непрерывного функционирования технологических процессов
    • Организация аудита АСУ ТП на соответствие применимым требованиям

Описание соответствующих разделов и подразделов представлено в Приложении № 4.

Заключение
На основе поставленных в работе задач, получены следующие результаты:

  • проанализированы международные стандарты безопасности на уровне АСУ ТП: ANSI/ISA-99 «ISA-99 Security for Industrial Automation and Control Systems», NIST SP800-82 «Guide to Industrial Control Systems», «20 Critical Security Controls», NERC CIP;
  • определены проблемные зоны в обеспечении непрерывности безопасности на уровне АСУТП;
  • обоснована  необходимость разработки стандарта безопасности на уровне АСУ ТП для российских условий.
  • проведен анализ следующих методик оценки зрелости: Open Information Security Management Maturity Model (O-ISM3); Enterprise Information Management Maturity Model (EIM MM); NISTIR-7358 методология PRISMA; Community Cyber Security Maturity Model (CCSMM);
  • обоснована необходимость разработки собственной модели зрелости;
  • разработана адаптивная модель зрелости и методика ее применения;
  • разработана функциональная модель процесса «Управлять непрерывностью безопасности бизнеса»;
  • обосновано применение указанных моделей зрелости и функциональной    для управления непрерывностью безопасности бизнеса на уровне АСУ ТП;
  • разработан проект структуры стандарта обеспечения непрерывности безопасности бизнеса на уровне АСУТП.

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

  • модель зрелости необходимо предложить экспертному сообществу и необходимо ее адаптировать на основе полученных замечаний;
  • разработанная функциональная модель является высокоуровневой моделью, которая в дальнейшем подлежит детализации;
  • структура и содержание проекта безопасности на уровне АСУ ТП необходимо предложить экспертному сообществу для утверждения и дальнейшей проработке.

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

Ваша оценка: Пусто Средняя: 10 (2 голосов)
Школа IT-менеджмента Экономического факультета АНХ, 119571, Россия, г. Москва, проспект Вернадского, д. 82 корп. 2, офис 207, тел.: +7 (495) 933-96-00, Copyright @ 2008-2009