КОНФИГУРИРОВАНИЕ  КОМПОНЕНТОВ  ЗАЩИТЫ  ВСТРОЕННЫХ  УСТРОЙСТВ  НА  ОСНОВЕ  ЭВРИСТИЧЕСКОГО  ПОДХОДА

Десницкий  Василий  Алексеевич

канд.  техн.  наук,  старший  научный  сотрудник  лаборатории  проблем  компьютерной  безопасности 
СПИИРАН, 
РФ,  г.  Санкт-Петербург

E-mail: 

CONFIGURING  SECURITY  COMPONENTS  OF  EMBEDDED  DEVICES  ON  THE  BASE  OF  A  HEURISTIC  APPROACH

Vasily  Desnitsky

candidate  of  Science,  senior  researcher  of  the  laboratory  of  computer  security  problems 
of  SPIIRAS, 
Russia,  St.  Petersburg

Работа  выполняется  при  финансовой  поддержке  РФФИ  (13-01-00843,  13-07-13159,  14-07-00697,  14-07-00417).

АННОТАЦИЯ

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

ABSTRACT

The  goal  is  to  develop  a  process  for  configuring  security  components  of  embedded  devices  through  combination  of  security  components,  using  expert  knowledge  in  the  field.  We  propose  a  heuristic  for  determining  an  order  for  accounting  non-functional  characteristics  in  the  combination  process  as  well  as  rules  for  the  use  of  the  multi-criteria  selection  of  the  security  components.

Ключевые  слова:  конфигурирование;  компоненты  защиты.

Keywords:  configuring;  security  components.

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

Фактически,  решается  задача  дискретной  оптимизации  на  множестве  конфигураций  с  целевой  функцией,  выражаемой  с  использованием  нефункциональных  показателей  и  ограничений  на  заданные,  как  функциональные,  так  и  нефункциональные  показатели  [3,  с.  201].  В  качестве  целевой  функции  решаемой  оптимизационной  задачи  рассматривается  упорядоченный  набор  из  нескольких  нефункциональных  показателей,  каждый  из  которых  подвергается  либо  минимизации,  либо  максимизации  в  зависимости  от  семантики  нефункциональной  характеристики,  лежащей  в  основе  рассматриваемого  нефункционального  показателя  (p1→min/max,  p2→min/max,  p3→min/max,…).  Порядок  показателей  определяется  на  основе  эвристического  подхода.

Стадия  1  включает  определение  функциональных  требований  защиты,  которые  нужно  реализовать  в  процессе  разработки  комбинированного  механизма  защиты.  Данные  требования  получаются  на  основе  анализа  спецификации  целевого  устройства  с  использованием  методов  аналитического  моделирования  действий  нарушителя  с  использованием  существующих  моделей  нарушителя  [2,  с.  7].  Примером  является  следующее  требование  защиты:  «секретность  бизнес-данных  устройства  должна  осуществляться  с  использованием  симметричного  шифрования  с  ключами  не  менее  128  бит».

Стадия  2  включает  действия  по  определению  нефункциональных  ограничений,  существенных  для  проектируемого  данного  устройства.  Источником  возможных  нефункциональных  ограничений  является  методология  MARTE,  являющаяся  де-факто  стандартом  [4,  c.  38],  где  релевантные  нефункциональные  показатели,  характерные  для  встроенных  устройств,  специфицированы  с  использованием  UML.  В  частности,  используются  нефункциональные  ограничения,  построенные  на  основе  следующих  классов  доменов  знаний:  HW_Physical,  HW_PowerSupply,  HW_StorageManager,  HW_Computing,  HW_Communication  [4,  c.  38]. 

На  стадии  3  для  каждого  функционального  требования  защиты  осуществляется  определение  множества  альтернатив  компонентов  защиты,  которые  его  реализуют.  Например,  для  требования  секретности  бизнес-данных  определяется  набор  криптографических  алгоритмов  симметричного  блочного  шифрования  заданной  стойкостью  с  установленной  длиной  ключа,  таких  как  AES/128/192/256,  IDEA  и  др.

На  стадии  4  осуществляется  определение  правил  выбора  компонентов  защиты,  исходя  из  связей  между  ними  с  учетом  семантики  компонентов  защиты,  установленных  требований  защиты  и  сценариев  использования.  Каждое  такое  правило  представляется  в  виде  формальной  четверки,  имеющей  следующие  элементы  (req,  Alts,  reason,  justif),  где  req  —  формулировка  функционального  требования  защиты,  Alts  −  набор  альтернатив  компонентов,  каждый  из  которых  реализует  данное  требование,  reason  —  причинно-следственная  связь  в  определении  предпочтительности  компонентов  из  Alts  в  зависимости  рассматриваемых  для  данного  требования  нефункциональных  показателей  (т.  е.  формулировка  критерия  выбора)  и  justif  —  фактическое  обоснование  предлагаемого  порядка  предпочтительности  компонентов  из  Alts  для  данного  функционального  требования  защиты.

На  стадии  5  производится  определение  значений  нефункциональных  ограничений  для  заданных  компонентов  защиты  следующими  способами:  путем  сбора  данных  от  конкретных  производителей  используемых  программно-аппаратных  модулей;  эмпирически  —  на  основе  программного  моделирования  компонентов  защиты  (когда  это  возможно);  экспертно  —  с  учетом  предыдущего  опыта  работы  с  такими  или  сходными  компонентами.  Так,  например,  для  каждого  из  имеющихся  альтернативных  алгоритмов  удаленной  аттестации  критических  бизнес-данных  встроенного  устройства  определяется  величина  необходимой  оперативной  памяти  (Kб),  которое  устройство  должно  предоставить,  и  объем  коммуникационного  ресурса,  расходуемого  на  передачу  аттестующих  подписей  доверенному  серверу  в  единицу  времени  (Mbit/sec). 

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

На  стадии  7  определяется  порядок  учета  рассматриваемых  нефункциональных  ограничений  в  зависимости  от  относительной  важности  каждого  из  них  с  использованием  эвристики,  предложенной  в  [3,  c.  201].  Данная  эвристика  задает  общий  алгоритм  приоритезации  нефункциональных  ограничений  встроенного  устройства.  По  существу,  для  каждого  нефункционального  ограничения  выделяется  набор  специфичных  функциональных  и  нефункциональных  признаков  встроенного  устройства,  таких  как  «наличие  постоянного  источника  питания»,  «возможность  замены  устройства  или  аккумулятора  без  ущерба  для  предоставляемых  им  сервисов»,  «высокая  зависимость  достижения  бизнес-целей  устройства  от  энергоресурсов»  и  др.  Для  каждого  такого  признака  предопределено  значение  ранга  (например,  с  заданием  значений  от  1  до  3,  где  1  —  низкая  важность,  3  —  высокая  важность)  в  зависимости  от  критичности  данного  признака  для  выполнимости  заданного  нефункционального  ограничения  (например,  ограничения  на  ресурс  энергопотребления).  В  результате  спецификация  целевого  встроенного  устройства  анализируется  на  предмет  наличия  у  него  обозначенных  признаков.  Для  каждого  нефункционального  ограничения  выбирается  максимальное  значение  ранга  по  всем  выявленным  у  разрабатываемого  устройства  признакам,  в  соответствии  с  которыми  происходит  упорядочивание  уже,  собственно,  нефункциональных  ограничений.  При  этом  ограничения,  получившие  одинаковые  результирующие  значения  ранга,  упорядочиваются  между  собой  согласно  порядку,  предопределенному  экспертно  [3,  с.  201]. 

На  стадии  8  осуществляются  комбинаторный  перебор  альтернатив  компонентов  защиты  и  вычисление  суммарных  значений  нефункциональных  показателей  наборов  компонентов  защиты  (конфигураций).  Стадия  включает  также  выбор  оптимальной  конфигурации  на  основе  полученных  значений  [1,  c.  45].  В  частности,  в  случае  большого  числа  рассматриваемых  функциональных  требований  защиты  и  имеющихся  альтернатив  компонентов  защиты  на  данной  стадии  целесообразно  применять  разработанное  программное  средство  Конфигуратор,  позволяющее  автоматизировать  процесс  перебора  и  вычисления.  Если  при  установленных  ограничениях  решений  оптимизационной  задачи  не  существует,  на  стадии  8  предлагается  ряд  конфигураций,  которые  смогут  быть  реализованными  при  ослаблении  определенных  ограничений  (в  частности,  увеличения  объемов  аппаратных  ресурсов  устройства,  выделяемых  на  работу  компонент). 

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

1. Десницкий  В.А.,  Котенко  И.В.  Проектирование  защищенных  встроенных  устройств  на  основе  конфигурирования  //  Проблемы  информационной  безопасности.  Компьютерные  системы.  —  №  1.  —  2013.  —  c.  44—54.
2. Десницкий  В.А.,  Чеулин  А.А.  Обобщенная  модель  нарушителя  и  верификация  информационно-телекоммуникационных  систем  со  встроенными  устройствами  //  Технические  науки  —  от  теории  к  практике.  —  №  39.  —  2014.  —  c.  7—21.
3. Desnitsky  V.  and  Kotenko  I.  Expert  Knowledge  based  Design  and  Verification  of  Secure  Systems  with  Embedded  Devices  //  Lecture  Notes  in  Computer  Science.  Springer-Verlag.  —  vol.  8708.  —  2014.  —  p.  194—210.
4. Object  Management  Group.  The  UML  Profile  for  MARTE:  Modeling  and  Analysis  of  Real-Time  and  Embedded  Systems.  Version  1.1.  —  2011  /  [Электронный  ресурс].  —  Режим  доступа:  —  URL:  http://www.omg.org/spec/MARTE/  (дата  обращения:  15.10.2015).