Разработка стратегии защиты от киберугроз – непростая задача, особенно для промышленных систем и Интернета вещей. В процессах проектирования, разработки, интеграции, использования и сопровождения таких систем принимает участие большое количество сторон.
Модель зрелости для безопасности
Правильный выбор мер и средств обеспечения безопасности не всегда очевиден. Более того, локальные бизнес-цели и мотивированные ими решения по безопасности, принимаемые различными участниками процесса обеспечения безопасности (например, производителем и потребителем OT-продуктов и услуг), могут оказаться не только разными, но и несовместными. Возможно, самым неприятным аспектом в этой ситуации является непонимание одной из сторон ограничений, потребностей и аргументов принятия решений по безопасности другой стороны.
Конечная цель модели зрелости безопасности IoT, описанной группой авторов под эгидой Industrial Internet Consortium (IIC IoT Security Maturity Model – IoT SMM) – обеспечить соответствие способов защиты от киберугроз реальным бизнес-потребностям. Задача – сформировать конкретное описание состояния достаточной безопасности для системы, помочь ответственным за безопасность данной системы лицам сфокусироваться на наилучших способах достижения этого состояния и определить соответствующие меры защиты. Зрелая с точки зрения безопасности система характеризуется достаточным набором мер защиты, которые не влияют негативно на ее функциональность. При этом определение «достаточности защиты» и понятие «негативно влиять на функциональность» для каждой системы свои.
Рассмотрим возможные позиции гипотетических производителя ПО SCADA-системы и его клиента. Например, в продукте производителя обнаруживается уязвимость. В интересах клиента может быть немедленное исправление уязвимости при помощи обновления. Разработчик же может медлить с выпуском исправлений в силу целого ряда причин, стараясь отложить исправление до выпуска следующей версии.
Для производителя выпуск исправления – это отвлечение ресурсов от выпуска основного продукта, которого ждут на рынке. Обновлением безопасности нового клиента не получить, а благодаря новой функциональности продукта – можно. Работу над выпуском исправлений никто не оплачивает, затраченные на нее ресурсы рассматриваются как убыток. Выпуская обновления, производитель множит поддерживаемые версии продукта, что усугубляет проблему согласованности изменений в этих версиях. Перечисленными факторами затраты не ограничиваются – нужно поддерживать доставку исправлений до клиентов теми способами, которые клиента устроят, и поддерживать осведомленность о необходимости обновления. Не выпуская обновлений, производитель откладывает работу до следующего основного выпуска, когда либо актуальность проблемы станет ниже, либо можно будет одним исправлением сразу решить целый ворох проблем, а это экономия и на разработке, и на тестировании.
Возможна и обратная ситуация. В ряде случаев клиент может пожелать получать обновления в аккумулированном виде – как кумулятивные исправления или уже в составе новой версии продукта, который более эффективно решает его производственные и бизнес-задачи и где исправления безопасности будут сделаны более правильно и основательно. Ведь наладить процесс управления изменениями на предприятии – дело сложное и дорогое. Особенности реализации систем автоматизации и технологического процесса предприятий в ряде индустрий вообще не позволяют устанавливать обновления иначе как в редкие периоды остановки производства. Установка исправления может грозить проблемами совместимости с окружением продукта в инфраструктуре клиента. Все подобные обновления на стороне клиента в идеале должны проходить процедуру предварительного тестирования, которое не всегда возможно оперативно выполнить – по техническим причинам или даже ввиду формальных ограничений, обусловленных спецификой производства.
Поскольку даже в отношении такой, казалось бы, простой меры защиты, как выпуск и установка обновления, изначальные позиции производителя и клиента могут не совпадать, им нужно предложить стратегию выбора, которая приведет их к согласованному решению.
Архитектура выбора в модели зрелости безопасности
Архитектурой выбора и ядром модели зрелости в безопасности является иерархия практик обеспечения безопасности (security practices). Практикой обеспечения безопасности, к примеру, является реализация контроля доступа, защита данных при их хранении и передаче или управление обновлениями безопасности. Чтобы максимально упростить процесс выбора, на самом верхнем уровне группы практик объединяются в домены. Три верхнеуровневых домена безопасности включают:
- управление безопасностью и организационные меры (Governance);
- обеспечение безопасности в силу конструкции (by design, Enablement);
- укрепление безопасности (Hardening).
Приоритет того или иного домена для производителя определяется потребностями бизнеса и особенностями системы (но первые прежде последующих).
Название «архитектура выбора» для иерархии практик безопасности не означает, что выбор должен быть сделан в пользу единственной опции. Даже при наличии процедур по укреплению состояния безопасности нельзя оставлять системы небезопасными by design, и наоборот, любые системы должны предусматривать возможность реализации оперативных мер защиты. В любом случае организационные меры – будь то программа безопасности или политика безопасности для цепочки поставок – являются основой уверенности в эффективности технических мер. Меры из этих доменов также должны быть запланированы.
На втором уровне каждый из доменов делится на три поддомена, которые классифицируют практики безопасности в соответствии с проблемой, на решение которой они нацелены. И наконец, каждый поддомен ссылается на две практики, каждая из них решает определенную задачу. Пример: управление безопасностью (Governance) включает поддомен управления зависимостями (supply chain and dependencies management), который, в свою очередь, состоит из обеспечения безопасности цепочки поставок (supply chain risk management) и управления зависимостями от подрядчиков, поставщиков сервисов и других сторонних субъектов (third party dependencies management) (рис. 1).
Рис. 1. Иерархия доменов, поддоменов и практик безопасности
Зрелость безопасности IoT
Чтобы устанавливать приоритеты и сравнивать реализацию мер безопасности, требуется шкала измерения. Оценивать эффективность метода защиты от киберугроз, перенесенного из классической ИT-безопасности в среду Интернета вещей, можно по двум параметрам. Первый – насколько хорошо реализован сам подход и систематизировано его применение – так называемая полнота реализации (comprehensiveness).
Очень важно отметить, что полнота – это еще не зрелость. Банковское веб-приложение требует наиболее полного подхода, а веб-приложение для сравнения текущего времени в разных часовых поясах может ограничиться рассмотрением сценариев работы с ним для выявления потенциальных проблем. Зрелый подход для приложения работы со временем будет недостаточным для банковского приложения. То есть зрелость в отличие от полноты – величина относительная.
Второй параметр, который имеет значение именно для Интернета вещей, – насколько специфичным должен быть подход с учетом требований индустрии или даже конкретной системы. Оценка угроз для устройств, создаваемых, к примеру, в автомобильной индустрии (и многих других), должна фокусироваться на предотвращении в первую очередь физической опасности для жизни и здоровья людей, для окружающей среды. Значимые угрозы для медицинского устройства – те, что способны вызвать изменение специальных параметров его работы, иногда даже незначительное (например, дозировка лекарства для пациента). Смещение фокуса на специфичные проблемы (scope) для реализации конкретной практики безопасности также напрямую определяет ее зрелость, если говорить об Интернете вещей. Здесь мы рассматриваем три варианта: общая неспецифичная реализация (General), специфичная для индустрии (Industry) и специфичная для системы (System). Последний вариант важен, поскольку сейчас появляется много решений на стыке индустрий или просто специального назначения, из тех, что мы не видели раньше, например «умный дом».
Таким образом, уровень зрелости определяется с учетом полноты реализации практики безопасности и специфики ее реализации для приложения Интернета вещей. Каждое приложение (организация, система, отдельное решение) требует разных полноты и специфичности. Значит, и целевой уровень зрелости для разных приложений будет разным. Текущий уровень зрелости измеряется относительно ее целевого уровня, который задается профилем зрелости безопасности.
Набор пар полнота + специфика (comprehensiveness + scope) по всем практикам безопасности называется профилем безопасности (Security Maturity Profile). Если такой набор определяет цели для конкретной системы, то он называется целевым профилем зрелости безопасности (Security Maturity Target). Это подробнейшим образом расписанные 36 параметров, по два на каждую практику.
В начале процесса описания целевого профиля зрелости безопасности на уровне бизнеса определяются приоритетные направления развития безопасности, связанные с верхнеуровневыми доменами. Далее установленные цели и связанные с ними уровни используются как умолчания (defaults), т. е. базовые уровни полноты и специфичности, от которых технические специалисты отталкиваются в своих предложениях по реализации практик безопасности. Использование бизнес-приоритетов в качестве умолчаний для уровня полноты реализации мер защиты позволяет упростить процесс постановки задачи обеспечения безопасности. Соответствующая процедура описана в документе IoT Security Maturity Model: Practitioners Guide.
Пример моделирования
Чтобы лучше объяснить, как используется модель зрелости безопасности Интернета вещей для долговременного планирования задач обеспечения безопасности и расстановки приоритетов в реализации мер, приведем пример.
Рассмотрим систему управления отоплением, кондиционированием и вентиляцией на некотором предприятии. Система включает непосредственно управляющие контроллеры, системы SCADA, консоли человеко-машинного интерфейса, сети и системы связи. Консоли могут быть доступны извне для удаленного управления и быть, в частности, точкой входа в систему для нарушителя, как это было в известной атаке на ритейлинговую сеть Target.
Объектом оценки зрелости безопасности может быть любой из компонентов или вся система в целом. Рассмотрим последний вариант.
С точки зрения системного интегратора, который непосредственно несет ответственность за работу системы, для уже функционирующей системы приоритетом является укрепление состояния ее безопасности. С этой целью проводится анализ уязвимостей, осуществляется реализация управления обновлениями программного обеспечения и прошивок оборудования.
Кроме того, интегратору требуются анализ и моделирование угроз, определенный уровень гарантий, что атака не происходит со стороны подрядчиков и не является виной поставщиков, которые не хотят либо не могут исправлять уязвимости в ПО или оборудовании своего производства. Эти практики, а также управление и контроль доступом к системам управления реализуются в соответствии с общими сценариями работы системы и доступа к ней (второй уровень полноты – аd hoc). Для отдельных компонентов необходима физическая защита. Прочие практики либо не требуются вовсе, либо реализуются на минимальном уровне. При выполнении мер безопасности нужно убедиться, что система соответствует принятым в индустрии стандартам и требованиям, поэтому показатель compliance будет специфичен для индустрии.
Суммируется целевой профиль зрелости безопасности в виде диаграммы (рис. 2), причем показатели полноты и специфичности практики оцениваются по отдельности.
Рис. 2. Целевой профиль зрелости безопасности для системы управления отоплением, кондиционированием и вентиляцией
Помимо создания целевого профиля зрелости безопасности для конкретной инсталляции системы можно оценить текущее состояние зрелости безопасности для системы и затем проанализировать расхождения текущего уровня с целевым. Визуализация расхождений может быть проведена на основе модных heat map или диаграмм типа «паутина», но самый удобный способ – при помощи по-разному заштрихованных столбчатых диаграмм, где штриховка показывает различия в показателе специфичности (scope) для каждой практики. На рис. 3, взятом из SMM Whitepaper, для простоты показана визуализация анализа расхождений на уровне поддоменов.
Рис. 3. Визуализация анализа расхождений текущего и целевого профиля зрелости безопасности
Использование модели зрелости позволяет оптимизировать постановку задачи безопасности, т. е. определить уровень «достаточной безопасности», провести оценку и планирование объема работ, необходимых для ее достижения с требуемой детализацией с уровня доменов безопасности до отдельных практик.
Заключение
Мы начали работать над моделью зрелости безопасности Интернета вещей (IoT Security Maturity Model – IoT SMM) в рамках Industrial Internet Consortium (IIC) в марте 2017 г. До того времени подгруппа Security Applicability, которая в рамках консорциума занимается как раз вопросами применения практик безопасности к реальным приложениям Интернета вещей, уже «смотрела в сторону» модели зрелости, но подход, который сейчас описан в документах, появился именно тогда, весной 2017 г. Примерно через год вышел базовый документ IoT Security Maturity Model: Description and Intended Use (текущая версия доступна по ссылке). В феврале 2019 г. вышло объемное руководство по применению модели IoT Security Maturity Model: Practitioners Guide (также доступен для скачивания). В настоящее время группа авторов работает над отдельными приложениями IoT SMM, а также над программой обучения ее использованию.
