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

Цифровые бреши в операционных технологических устройствах могут обойтись дорого

Приведем некоторые примеры киберуязвимостей, которые повлекли за собой серьезные финансовые потери для компаний:

  • ошибки безопасности в некоторых моделях автомобилей Jeep/Chrysler/Dodge привели к расходам на их устранение, внесение изменений в конструкцию и к отзывам автомобилей, что обошлось компании более чем в 1 млрд долл. [1];
  • ошибки в системе зарядки батареи телефона Samsung Note 7, в некоторых случаях закончившиеся взрывом, заставили компанию отзывать/ремонтировать свои устройства и повлекли финансовые потери в размере 17 млрд долл. [2];
  • требование обновления программного обеспечения, управлявшего маневрированием в Boeing 737 MAX, вынудило компанию на несколько месяцев поставить свои самолеты на прикол, что обошлось ей более чем в 18 млрд долл. [3].

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

Для ОТ, к которым относятся, например, распределенные системы управления предприятиями, генерирующими электроэнергию, или цифровые системы управления двигателями самолетов, характерны дополнительные затраты, поскольку любое вносимое в систему изменение сопряжено с дополнительными рисками (в том числе с рисками причинения вреда здоровью людей или имуществу). Перед началом разработки любых обновлений эти риски необходимо оценивать и устранять. Если первоначальная разработка заняла, допустим, четыре часа, то на исправление ошибок системы, уже находящейся в эксплуатации, у команды, осуществляющей сопровождение/интеграцию продукта, может уйти около 2 тыс. часов, которые придется потратить на целый ряд действий: получение необходимых сведений, проведение испытаний, оценка, анализ, исправление, выполнение совместных с клиентами мероприятий по развертыванию системы и по раскрытию соответствующей информации. Когда устройства функционируют в производственной среде (на электростанциях, в передающих/распределительных сетях, на авиационных платформах самолетов или в системах визуализации больниц), их ремонт обходится еще дороже.

Безопасность в жизненном цикле продукта

Рис. 1. На протяжении жизненного цикла разработки продукта имеется множество средств для обеспечения его безопасной разработки

На рис. 1 приведена цикличная схема итеративного процесса разработки продукта, и на каждом этапе разработки есть вероятность нарушения системы безопасности.

Обучение безопасной разработке

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

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

Обучение навыкам безопасной разработки должно быть непрерывным, что реализуется путем привлечения инженеров и разработчиков продукта на различных этапах обеспечения его безопасности.

Требования к безопасности

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

Если мы, например, проектируем продукт для распределенной системы управления, интегрированный с гидротурбиной, то используем стандарт NERC CIP-005, разработанный North American Electric Reliability Corporation (NERC) для защиты критически важной инфраструктуры (Critical Infrastructure Protection, CIP), который требует определения «периметра электронной безопасности», а стандарт NERC CIP-007 — процедуры для организации безопасного доступа — регламентирует, в частности, изменения параметров доступа по умолчанию. Внедрение этих стандартов и проверка на соответствие им позволяют исключить еще 13% вызовов консультантов по промышленным системам управления. Слабые места сразу устраняются благодаря соблюдению требований стандартов.

Моделирование угроз и проектирование элементов управления безопасностью

Обучение безопасной разработке и разработка с соблюдением требований стандартов — достаточно недорогие способы повышения уровня безопасности на ранних стадиях процесса создания изделия, что, впрочем, еще не дает полных гарантий. Моделирование угроз помогает систематически продумывать компоненты продукта и определять требования к обеспечению его безопасности, на основе которых может быть создана базовая система контроля. Противоборство различных мнений в отношении продуктов ОТ сегодня обостряется. Эксперты по безопасности программного обеспечения или ИТ-безопасности считают, что модель угроз представляет собой диаграмму потока данных (data-flow diagram, DFD) с полным описанием фронта атаки, в то время как инженеры по продуктам предпочитают выполнять комплексный анализ процессных рисков (process hazard analysis, PHA), анализ режимов отказов и последствий (failure modes and effects analysis, FMEA) и пр. Комплексный анализ различных подходов помогает разобраться с архитектурой и гарантировать непрерывность процесса обеспечения безопасности, призванного предотвратить случаи нанесения травм и причинения физического ущерба имуществу.

  • В принципе, лучше начинать с того, что у вас уже имеется, будь то PHA, FMEA, стандарты или метрики, проводя оценку обучения и использования модели угроз, и постепенно закрывать еще не охваченные участки. В противном случае все будет отдано на откуп инженерам, которые презирают экспертов по безопасности, а это, в свою очередь, будет препятствовать налаживанию сотрудничества с целью выстраивания эффективной системы безопасности. Перечислим некоторые из уроков, извлеченных в процессе превращения моделирования угроз в эффективный инструмент обеспечения безопасности продуктов OT.
  • На стадии декомпозиции продуктов программисты выполняют стандартизацию на основе DFD. Эти диаграммы не рассматриваются в качестве стандарта разработчиками и инженерами OT, которые вместо них используют (в зависимости от продукта или отрасли) диаграммы процессных потоков, функциональную декомпозицию продуктов, деревья доказательств/целей или диаграммы конвейеров и инструментального оснащения. Выстраивание на основе уже существующих процессов экономит время и энергию по сравнению с использованием традиционных для программного обеспечения практик, выполнять которые принуждают инженеров. DFD — это не модель угроз.
  • Использование бесплатных инструментов для моделирования угроз помогает «автоматизировать» процесс оценки восприимчивости изделия к угрозам. Мы обнаружили, однако, что из-за отсутствия готовых физических образцов отдельных компонентов ОТ и шаблонов для ОТ-систем возможно большое количество ложных срабатываний, что лишает инженеров контроля за процессом. Это обходится дорого и мешает процессу сотрудничества между инженерами, разработчиками и экспертами по безопасности. Вместе этого инженеры по безопасности могут выбрать наиболее популярные «шаблоны атак», связанные с общими компонентами ОТ, и организовать обсуждение производных возможностей продукта, их оценки и ранжирования. Разбирая последствия атак, можно вовлечь инженеров в беседу и уже общаться с ними на понятном им языке.
  • Извлечение шаблонов стандартных атак из списков Common Weakness Enumeration (CWE) компании MITRE или Common Attack Pattern Enumeration and Classification (CAPEC) сулит определенную выгоду. В большинстве таких списков уже описаны концепции смягчения рисков, что ускоряет переговоры с инженерами, когда те пытаются решить возникающие проблемы, и обеспечивает семантическую основу для определения сильных и слабых сторон выбранного способа обучения безопасности и применения стандартов.
  • Очень эффективной оказалась геймификация этого процесса. Мы сформировали команды, в состав которых входили инженер, специалист по компонентам и эксперт по безопасности, а затем по очереди разрабатывали сценарии атаки с помощью запросов к CAPEC, для чего другая команда должна была описать существующие и возможные решения по реагированию на них. За дельные советы предусматривалось вознаграждение, и в течение нескольких часов мы получали индивидуальную картину ключевых угроз без необходимости составления ненужных диаграмм.
  • Как правило, выявление восприимчивости к угрозам, связанным с CWE и CAPEC, для которых уже существуют готовые решения, полученные на основе регулярного обучения, стандартизации, бенчмарков или других средств анализа безопасности с имеющимися тестами, — пустая трата времени.

Оценка ПО с открытым кодом и предложений независимых поставщиков

Продукты ОТ сегодня редко проектируют, принимая во внимание лишь оборудование. Кроме того, для проверки концепции и создания прототипов зачастую используют программное обеспечение с открытым кодом и продукты от независимых поставщиков. Эффективные цепочки поставок — ключ к доступной доставке дорогостоящих продуктов. Однако цепочки поставок могут создавать дополнительные риски, если мы не отслеживаем, не понимаем и не контролируем решения, принимаемые поставщиками, до начала закупок и интеграции. Вспомним о взломе системы обновления сервера M.E.Doc, что впоследствии, при развертывании бухгалтерского программного обеспечения, привело к распространению вируса NotPetya. Ущерб от этого вируса исчислялся миллионами. Ключом к доступной и эффективной безопасности на основе ПО с открытым кодом и продуктов независимых поставщиков является масштабируемость. То есть нужно решить, что имеет смысл отслеживать и как сортировать риски на основе ожидаемого использования, лицензий и интеграции. А при проведении многоуровневых исследований стоит тратить драгоценное время только на продукты с изначально присущими им высокими рисками.

Тестирование и проверка средств контроля безопасности

Следующая возможность обеспечения безопасности изделия связана с интеграцией тестирования в среду сборки/разработки. Результаты экспериментов показывают, что в 40% ситуаций случайная выборка аварийного дампа почти сравнима по стоимости с проведением полной проверки на наличие уязвимостей. Экстраполировать этот вывод сложно, но можно признать, что при сокращении времени тестирования и расширения области его охвата, скорее всего, удастся интегрировать тестирование в процесс разработки продукта.

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

  1. Объединяйте возможности автоматических инструментов, таких как статическое, динамическое и фаззинг-тестирование, с процессом оценки необходимости применения тестов при создании каждого конкретного сегмента продукта.
  2. Недостатки автоматизированного тестирования компенсируйте выполнением тестов вручную для определенных метрик и связанных с продуктом рисков.
  3. Мы разработали более 200 стандартных рабочих процедур, позволяющих быстро выполнять дополнительные ручные тесты в рамках соглашения об уровне обслуживания (service-level agreement, SLA). Процедуры предусматривают проведение тестирования средств контроля, обеспечивающего обнаружение для 184 CAPEC и десятков дополнительных шаблонов атак, специфичных для наших продуктов. Это позволяет сократить циклы разработки и проводить оценку безопасности на протяжении всего процесса разработки продукта ОТ.
Встроенная безопасность корпоративных киберфизических систем
Рис. 2. Непрерывная обратная связь при тестировании — лучший способ гарантировать соответствие или избыточность базовых средств контроля модели угроз. Ключевое условие — автоматическое тестирование, недостатки которого устраняются путем быстрого выполнения вручную тестовых процедур

Быстрые тесты позволяют обнаружить в среднем около шести уязвимостей за сеанс, но, поскольку их можно встраивать в циклы разработки продуктов, время, необходимое для устранения уязвимостей, сокращается как до, так и после тестирования. На рис. 2 показаны примеры уровней контуров обратной связи для разработчиков на конвейере сборки. Ручные проверки предназначены для перемещения элементов управления тестированием и политикой на более ранние стадии процесса, что можно сделать достаточно просто в случае стандартизации процедур, которые повторяются для различных инструментов и компонентов.

Для ОТ-продуктов с присущими им более высокими рисками вслед за тестированием по принципу прозрачного ящика следует проводить оценку углубленной защиты. Такой метод идеально подходит для ОТ-продуктов и корпоративных приложений, где соответствующий исходный код, образы встроенного программного обеспечения и учетные данные могут быть представлены заранее. В идеале после завершения разработки и до момента выпуска необходимо провести оценку продукта или приложения, с тем чтобы команда разработчиков могла принимать обоснованные решения в отношении учета рисков до передачи продукта или приложения клиентам. На рис. 2 показано, что при перемещении объектов вниз по конвейеру знания в области безопасности постоянно объединяются с общими политиками для формирования полной картины, позволяющей получить больше уверенности в надежности изделия.

Одобрение процедур безопасности

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

Группа реагирования на инциденты безопасности

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

***

Первоначальные инвестиции в методы обеспечения безопасности продукта — обучение, моделирование угроз и процедуры тестирования — могут быть достаточно велики, но они обеспечивают отдачу в виде снижения затрат на обеспечение безопасности в каждой конкретной точке жизненного цикла изделия. Для повышения эффективности надо уметь интегрировать результаты распределенных действий, направленных на обеспечение безопасности, для получения единой картины безопасности. Надеемся, что опыт GE окажется полезен всем отраслевым сообществам ОТ-продуктов.

Литература

1. S. Cobb. Cybersecurity and manufacturer: What the costly Chrysler Jeep hack reveals. Welivesecurity, 2015. Accessed on: Jan. 31, 2020. URL: https://www.welivesecurity.com/2015/07/29/cybersecurity-manufacturing-chrysler-jeep-hack (дата обращения: 13.11.2020).

2. Y. Lee. Note 7 fiasco could burn a $17 billion hole in Samsung accounts. Reuters, 2016. Accessed on: Jan. 31, 2020. URL: https://www.reuters.com/article/us-samsung-elec-smartphones-costs-idUSKCN12B0FX (дата обращения: 13.11.2020).

3. D. Gelles. Boeing expects 737 Max costs will surpass $18 billion. NY Times, 2020. Accessed on: Jan. 31, 2020. [Online]. URL: https://www.nytimes.com/2020/01/29/business/boeing-737-max-costs.html (дата обращения: 13.11.2020).

Кеннет Краутер (kenneth.crowther@ge.com) — руководитель направления обеспечения безопасности продуктов GE Global Research, менеджер программы безопасности корпоративных продуктов; Брайан Раст (brian.rust@ge.com) — старший менеджер программ кибербезопасности General Electric.

Kenneth G. Crowther, Brian Rust, Built-In Cybersecurity: Insights Into Product Security for Cyberphysical Systems at a Large Company, IEEE Security and Privacy, September/October 2020, IEEE Computer Society. All rights reserved. Reprinted with permission.