Операционные технологии в промышленном IoT не терпят исправлений в ИТ-стиле. «Анализ угроз» - надежное и эффективное решение

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

Каждый заказчик промышленного интернета вещей (IIoT), с которым я разговариваю, хочет максимально надежной защиты. Не Интернет вещей - промышленный Интернет вещей (IIoT).

Кто в организации клиента будет выполнять этот процесс и владеть им? Встречаясь после встречи с клиентами, создающими возможности IIoT, я сталкиваюсь с естественной, но иногда напряженной неуверенностью между ИТ-специалистами и специалистами в области OT / LOB, когда речь идет о безопасности IIoT.

Эта неуверенность в капитале - сама по себе - уязвимость системы безопасности, поскольку она задерживает существенное развертывание системы безопасности.

Согласно отчету DARKReading от InformationWeek, недавний опрос Forrester среди руководителей ИТ и OT / LOB показал, что ИТ-менеджеры и ИТ-менеджеры поровну разделяют вопрос о том, отвечают ли за безопасность ИТ или ОТ. Как сообщает Forrester, тревожным результатом этого противостояния является неприемлемо большое количество компаний - 59 процентов - готовы «терпеть от среднего до высокого риска в отношении безопасности Интернета вещей».

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

Обратите внимание на различия между корпоративными ИТ и ОТ:

• Доступность :
  ИТ-специалисты считают приемлемым 99% времени безотказной работы, тогда как OT требует 99,999% времени безотказной работы - разница между 8,76 часами и 5,25 минутами годового простоя.
  • Срок службы системы :
  ИТ-системы обновляются в среднем каждые три-пять лет. Системы ОТ, напротив, служат от 10 до 15 лет.
  • Установка исправлений :
  Исправления / обновления ИТ могут выполняться всякий раз, когда доступны обновления, но исправления / обновления OT рискуют прервать стратегические, приносящие доход промышленные операции.

Есть много других отличий ИТ / ОТ, например, разные подходы к облаку.

Однако все различия сводятся к универсальной потребности в наиболее устойчивой доступной безопасности IIoT.

Я поддерживаю подход, который помогает промышленным компаниям использовать с трудом извлеченные и долгие уроки ИТ, чтобы перейти к более продвинутому уровню безопасности IIoT. IIoT спроектирован и развернут с учетом разнообразных требований OT. Некоторые считают, что системы OT - это еще одна форма центра обработки данных, сильно защищенное ядро ​​корпоративных ИТ.

Есть несколько многообещающих идей, которые можно адаптировать на основе многолетнего опыта в сфере ИТ. Использование этих идей и последующее добавление к ним для обеспечения нового уровня безопасности IIoT с учетом конкретных потребностей OT. Среди этих адаптаций - разделение сетей конечных точек, микросегментация и анализ поведения пользователей (UBA). Я расскажу об этом в следующих статьях.

С исправлением , IT и OT говорят на разных языках. Введите «анализ угроз».

Мы понимаем, что процесс установки исправлений направлен на обновление, исправление или улучшение программного обеспечения. Обычно это быстрое решение, причем зачастую случайное. Однако, когда дело доходит до установки исправлений, прямой перенос повседневной ИТ-практики на OT не всегда возможен.

Когда дело доходит до установки исправлений, ИТ и ОТ говорят на разных языках.

Очень важно, чтобы отрасль IIoT - ИТ и OT объединилась на благо своих предприятий. Это потребует более глубокого мышления и большего воображения для разработки надежных методов кибербезопасности. По необходимости эти операции должны быть более гибкими и эффективными, чем рефлексивное исправление.

Патчи могут создавать проблемы для ОТ. Как мы видим с патчами для уязвимостей CPU Meltdown и Spectre, иногда патч может усугубить ситуацию. Ранние исправления для Meltdown и Spectre повлияли на производительность всей системы.

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

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

Наконец, существует проблема относительной сложности и хрупкости систем ОТ по сравнению с ИТ-системами.

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

Даже когда компании могут отключать машины для установки исправлений - когда они возобновляют работу - результаты могут быть непредсказуемыми. Это не та же система, потому что в патче добавлены подстановочные знаки, которые могут распространяться через другие элементы системы.

В ОТ непредсказуемость недопустима.

Итог: Должен быть лучший способ защиты систем IIoT, чем рефлексивное исправление ИЛИ игнорирование угрозы безопасности, потому что исправление просто невозможно - по всем причинам, которые я только что изложил.

ЛУЧШИЙ СПОСОБ:«АНАЛИЗ УГРОЗЫ»

Лучший подход в ОТ - это изучить проблемы безопасности гораздо более детально, чем сейчас. Я предлагаю использовать старый подход к анализу угроз при установке исправлений.

Первый шаг в анализе угроз:

Не предпринимайте немедленных действий. Это означает, что откладывать исправления, а не исправления, что-либо еще. Подождите секунду, пока мы не проверим, действительно ли существует уязвимость в системе, и если да, то как ее можно использовать?

Следует учитывать несколько факторов.

Некоторые системы, которые работают глубоко внутри предприятий, действительно могут иметь уязвимости. Поскольку система настолько изолирована на предприятии, реальная угроза безопасности меньше чем риск выключения системы для установки исправлений - при условии, что исправление вообще существует.

Изменения расчетов при оценке систем, подключенных к облаку или Интернету, - вот где риск безопасности, очевидно, намного выше.

Анализ угроз:

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

Анализ угроз: также подтвердит уязвимость. Важно задать еще один вопрос:если эта уязвимость может быть использована некоторыми угрозами, есть ли способ остановить это без исправления ?

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

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

Эта дополнительная прозрачность предоставит клиентам больше информации для принятия решений о правильных мерах безопасности для затронутых систем. Эксперты по безопасности должны быть уверены, что исправление, по крайней мере, сохранит тот же уровень риска, который существовал до обнаружения уязвимости.

Анализ угроз: должен быть предельно детализированным. Если на предприятии работает 100 устройств, для каждого из них требуется собственный анализ угроз, который будет включать сравнение уязвимостей и преимуществ исправлений, а также итоговое «меню» параметров безопасности.

Основная цель, конечно же, - повысить безопасность и в то же время максимизировать время безотказной работы OT.

Анализ угроз: является более тонким и многомерным, чем решения о внесении исправлений в систему.

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

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

То, что так хорошо работало в ИТ, просто не подходит ОТ.

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

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

Тот факт, что мы можем ясно видеть это лучшее будущее, не означает, что оно близко.

Но давайте приступим к делу вместе.