ЖУРНАЛ СТА 3/2013

изводителя устройства, операторов (ес- ли они предусмотрены) и конечных пользователей (включая соответствую- щую среду эксплуатации) и описывать в виде пар так называемых векторов атаки (то есть способов осуществления атаки) и эксплуатируемых ими уязвимо- стей (то есть незащищённостей или сбоев в программном или аппаратном обеспечении, позволяющих атаке до- стигнуть цели). В качестве примера вектора атаки можно привести кабель- ное Ethernet-соединение и предостав- ляемые через него типовые сервисы на- подобие HTTP, FTP, SSH или отладоч- ных агентов. Примером уязвимости может служить слишком простой или установленный по умолчанию пароль, или ошибка кодирования (например, отсутствие проверок переполнения сте- ка), или даже концептуальная ошибка проектирования (например, некор- ректная последовательность начальной загрузки). Самая трудная часть здесь – это предсказать и предотвратить все возможные векторы атаки и уязвимо- сти заранее. Чтобы оценка принесла плоды, не- обходимо проанализировать устройство в очень широком спектре потенциаль- ных угроз. Множество реальных совре- менных угроз возникло из предположе- ния, что устройство просто не может использоваться тем или иным спосо- бом. Stuxnet, в частности, атаковал ПЛК, расположенные в общей сети с инфицированными настольными и портативными компьютерами. Однако даже учитывая, что такая сеть изначаль- но не подключена к Интернету, вполне вероятно, что к ней иногда будут под- ключаться диагностические или ин- струментальные компьютеры. При оценке угроз важно рассматривать не только сами устройства, но и внешнюю среду, в частности, операторов и конеч- ных пользователей. В процессе оценки угроз для встраи- ваемого устройства необходимо сделать как минимум следующее. ● Произвести полный анализ жизненно- го цикла продукта , при этом необхо- димо учесть как разработчиков, так и изготовителей, дистрибьюторов, по- ставщиков и конечных пользовате- лей, чтобы получить полную картину их влияния на безопасность. Необхо- димо также оценить приоритет ки- бербезопасности и защиты информа- ции для данного устройства. ● Определить и описать все возможные входные точки атаки , при этом не сле- дует зацикливаться на сетевом досту- пе, так как существуют и другие вари- анты, например, физический доступ через USB или последовательные порты. Когда входные точки опреде- лены, нужно оценить уязвимости для каждой из них. Защищено ли устрой- ство от атаки через TCP-порт 80? Ис- пользуется ли межсетевой экран? Ес- ли нет, какие порты TCP/UDP от- крыты? Аналогично для физического доступа: поддерживает ли устройство загрузку с внешнего USB-носителя? Необходим также анализ возможных комбинаций входных точек. ● Построить матрицу рисков . Посколь- ку возможных вариантов атаки может быть множество, требуется оценка ве- роятности атаки по каждому каналу и возможного урона от такой атаки. ● Разработать стратегию сокращения рисков , исходя из заданных приори- тетов. Например, выигрышной стра- тегией может быть разбиение систе- мы на разделы с разными уровнями безопасности. В ряде случаев это мо- жет вести к усложнению архитекту- ры, однако эта стратегия окупается за счёт уменьшения объёма тестирова- ния и сокращения стоимости обнов- ления на более поздних стадиях жиз- ненного цикла. ● Создать техническую спецификацию, включающую в себя требования к без- опасности , полученные на основе предыдущих действий. Это равно- правная часть процесса разработки, но её следует расценивать как высо- коприоритетную. План работ по про- ектированию, разработке, тестирова- нию и сопровождению средств без- опасности должен стать частью обще- го рабочего плана. Шаг 2: проработка безопасной архитектуры Ответом на усиление значения без- опасности связанных устройств стало развитие ряда технологий и методоло- гий разработки. Одной из важных пара- дигм разработки безопасных устройств является использование готовых ком- мерческих (commercial off-the-shelf – COTS) системных компонентов, кото- рое позволяет обеспечивать безопас- ность, одновременно контролируя за- траты. В качестве примеров можно при- вести как сертифицируемые ОС и свя- зующее ПО, так и технологии виртуа- лизации, разбиения на разделы и вир- туальные среды исполнения, позволяю- щие увеличить уровень абстракции и разделения компонентов. В последнее время набирает особую популярность виртуализация, так как она позволяет выполнять несколько ОС на общей разделяемой аппаратной платформе. Это даёт проектировщикам дополнительную гибкость, а также поз- воляет более эффективно использовать возможности оборудования по сравне- нию с дизайном на базе одной ОС. Вир- туализация также предоставляет хоро- шую почву для распределения функ- циональности устройства по несколь- ким разделённым виртуальным средам, что позволяет разворачивать на одной физической платформе компоненты с повышенными требованиями к функ- циональной или информационной без- опасности и некритические приложе- 16 СТА 3/2013 ОБ ЗОР / В С Т РАИВ А ЕМЫЕ СИС Т ЕМЫ www.cta.ru Рис. 1. Пять шагов к обеспечению безопасности встраиваемых систем Оценка угроз Проработка безопасной архитектуры Выбор безопасной программной платформы Обеспечение безопасности приложений Цикл разработки и инструментарий Всесторонняя оценка безопасности устройства Изоляция функциональных блоков Использование безопасных компонентов Сертифицируемые платформы (ОС, гипервизор) Сертифицируемое/ безопасное связующее ПО Белые списки Оценка репутации источников Средства анализа кода Средства симуляции атак Средства автоматизированного тестирования Среда Ввод/ вывод Прото- колы © СТА-ПРЕСС