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

стемы, к которым предъявляются бо- лее жёсткие требования по безопас- ности. ● Связующее ПО . В зависимости от требований к системе уровень свя- зующего ПО может включать в себя либо базовую, либо расширенную функциональность в области сетевых коммуникаций (включая безопас- ность и беспроводные технологии), аудио, графики и т.п. Выбор связую- щего ПО особенно важен, с точки зрения обеспечения защиты комму- никаций, так как именно оно содер- жит криптографические библиотеки и компоненты реализации защищён- ных протоколов наподобие SSL и IPSec. Дополнительную защиту мож- но обеспечить, применяя межсете- вые экраны и авторизацию доступа. Связующее ПО, реализующее про- чую функциональность (например графический интерфейс), тоже сле- дует выбирать с учётом безопасности; в противном случае могут возникнуть непредвиденные уязвимости на си- стемном уровне. ● Средства симуляции оборудования . Симуляция оборудования на уровне процессора, отдельных плат и систе- мы в целом помогает ускорить про- цесс интеграции аппаратного и про- граммного обеспечения, так как га- рантирует доступность оборудования в нужном месте, в нужный срок и в достаточном количестве. (В процессе разработки встраиваемой системы это часто становится серьёзной про- блемой, так как пока прототип не бу- дет разработан, стабилизирован и произведён в достаточном количе- стве, ПО отлаживать будет физически не на чем. – Прим. пер. ) К тому же средства симуляции позволяют ис- пользовать более эффективные мето- дики отладки и тестирования, кото- рые на реальном оборудовании реа- лизовать физически невозможно (на- пример, выполнение кода от момента ошибки в обратном порядке, чтобы восстановить цепочку событий. – Прим. пер. ). ● Инструментарий . Инструменты, ис- пользуемые для тестирования, отлад- ки и статического анализа кода, иг- рают критическую роль в выявлении ошибок проектирования и в пред- отвращении просачивания небез- опасного кода в проект на ранних его стадиях. Средства автоматизирован- ного тестирования и симуляции обо- рудования также значительно уве- личивают эффективность процесса разработки. Шаг 4: обеспечение безопасности приложений Современные встраиваемые системы давно вышли за пределы традицион- ных узкоспециализированных устройств, выполняющих одну кон- кретную задачу. Сейчас в рамках одной встраиваемой системы могут сосуще- ствовать несколько приложений, при- чём их функциональность может рас- ширяться на всём протяжении жиз- ненного цикла устройства посредством динамического обновления как аппа- ратуры, так и ПО. Как и в случае с настольными и сер- верными приложениями, для встраи- ваемых систем критично наличие средств безопасности, так как они ста- новятся всё более открытыми для вре- доносного кода и несанкционирован- ного доступа к данным. Встраиваемые системы, поддержи- вающие динамическое обновление, мо- гут использовать для повышения без- опасности технику белого списка (whitelisting). Использование белого списка позволяет устройствам загру- жать и запускать только те приложения, которые подтверждены как безопасные; всё остальное ПО, не входящее в белый список, системой принято не будет. Родственная техника чёрного списка, подразумевающая поддержку актуаль- ного списка известного вредоносного ПО и вирусов, используется для пред- отвращения загрузки и запуска содер- жимого, входящего в запрещённый список. Поскольку чёрные списки гораздо объёмнее белых и гораздо чаще ме- няются, встраиваемым системам обычно недостаёт ресурсов для посто- янной поддержки актуальности чёр- ных списков, так как для этого не- обходимо наличие постоянного хра- нилища, средств сетевой синхрониза- ции, частых обновлений и т.п. Это де- лает белые списки более привлека- тельной стратегией для встраиваемых систем. Ещё одна техника, которую можно использовать для повышения без- опасности, – это оценка так называе- мой репутации источника данных. Если данные получены из источника с неизвестной или дурной репутаци- ей, приложение может определить, какие шаги следует предпринять: вы- полнить проверку целостности, от- вергнуть и т.п. Проверка репутации источников также способна помочь повысить производительность: если данные поступают из проверенных источников, то проверки безопасно- сти будут занимать меньше процес- сорного времени. Шаг 5: распространение мер безопасности на весь жизненный цикл продукции Требования к безопасности посто- янно меняются, так как постоянно ме- няются угрозы. По мере того как устройство набирает популярность (Stuxnet был ориентирован на широко распространённую модель ПЛК) и/или возраст на рынке, оно становится более подвержено атакам. В прошлом многие устройства не были рассчитаны на ди- намическое перепрограммирование и обновление в процессе эксплуатации (без существенных модификаций). Но это время прошло. Сегодня устройства обязаны поддерживать динамическое обновление, и не только для усовер- шенствования функциональности, но и для решения будущих вопросов без- опасности. Включение задач по обеспечению безопасности в процесс управления жизненным циклом изделия сегодня является первостепенной задачей. Ма- ло того – важна ещё и скорость, с кото- рой организация может реагировать на угрозы по мере их возникновения. Так- же не менее важным моментом являет- ся соответствие вашим стандартам без- опасности продукции выбранных вами поставщиков. В контексте безопасности разработчи- кам встраиваемых систем следует учиты- вать как минимум следующие аспекты управления жизненным циклом. ● Безопасность должна быть встроена во все стадии жизненного цикла . Безопас- ный дизайн должен присутствовать в системе изначально и быть основой всего жизненного цикла. Безопасную архитектуру нельзя добавить в случае необходимости. ● Будущие изменения должны быть пред- усмотрены заранее . Устройствам и си- стемам требуется возможность дина- мического обновления, исправления ошибок и модернизации; будущие обновления и мониторинг безопасно- сти необходимо включать в планы поддержки изначально. 20 СТА 3/2013 ОБ ЗОР / В С Т РАИВ А ЕМЫЕ СИС Т ЕМЫ www.cta.ru © СТА-ПРЕСС