Введение в безопасность систем ICS/SCADA

Автор: Tripp Roybal
Начиная с конца 60-х годов прошлого века, промышленные системы управления (Industrial Control System; ICS) появились практически во всех сферах, имеющих отношение к современной жизни: энергетика, промышленность, коммунальные системы и другие области.
С момента изобретения блочного цифрового контроллера в 1968 году и до середины 90-х промышленные системы управления были практически изолированы и могли работать с очень ограниченным набором входных и выходных данных из внешних источников. Однако с появлением дешевого оборудования, операционной системы Microsoft Windows, Active Directory и общей стандартизации, современные корпоративные сети стали получать и обрабатывать данные (а также выполнять другие множество других операций) из сетей за пределами традиционных ICS-сетей. Несмотря на то, что на данный момент предпринимается множество усилий по сегментации сетей связанных с информационными и промышленными технологиями, границы до сих пор остаются размытыми, что доставляем много головной боли специалистам по безопасности, работающим во многих индустриях.

Чем отличается ICS от SCADA 

Несмотря на то, что термины ICS (Промышленная система управления) и SCADA (Диспетчерское управление и сбор данных) часто используются как синонимы, между этими понятиями существует отличие. Термином ICS именуется общая технология, включающая в себя подкатегорию SCADA. Ниже перечислены примеры подкатегорий, которые включает в себя технология ICS:

Распределенные системы управления (DCS)

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

Программируемые логические контроллеры (PLC)

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

Диспетчерское управление и сбор данных (SCADA)

• В некотором смысле работают в качестве менеджеров.
• Диспетчерские сервера обычно не принимают решений.
• Диспетчерские сервера, как правило, перенаправляют команды от других систем и людей.

Системы архивных данных

• Собирают и хранят информацию касаемо статистики процессов, показаний датчиков, ввода/вывода и другие показатели.
• Могут быть необходимы для законодательного и нормативного регулирования.
• Обычно информация хранится в базах данных, например, в MSSQL или Oracle.

 Человеко-машинный интерфейс (HMI)

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

Удаленный терминал (RTU)

• Небольшие защищенные компьютеры, которые собирают и соотносят данные между физическими сенсорами и ICS-процессами.

Дополнительную сложность в ICS-среды вносят различные коммуникационные протоколы. Ниже перечислены как общие, так и специальные протоколы, которые используются в системах ICS:

• ANSI X3.28
• BBC 7200
• CDC Types 1 and 2
• Conitel 2020/2000/3000
• DCP 1
• DNP3
• Gedac 7020
• ICCP Landis & Gyr 8979
• Modbus
• OPC
• ControlNet
• DeviceNet
• DH+
• ProfiBus
• Tejas 3 and 5
• TRW 9550

Типичная архитектура ICS-среды
При проектировании ICS-среды должны удовлетворяться требования, связанные с высокой отказоустойчивостью, законодательными и нормативными актами и системой обновления, что серьезно ограничивает пространство для выбора. Чтобы соответствовать всем необходимым правилам, большинство ICS-сред строятся на базе трехуровневой структуры:

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

На среднем уровне, как правило, происходит сбор и обработка входных и выходных данных от других слоев. Устройства, работающие на этом уровне, обычно называются Полевыми контроллерами (Field Controller), которые включают в себя Программируемые логические контроллеры (PLC), Интеллектуальные электронные устройства (IED) и Удаленные терминалы (RTU). Полевые контроллеры могут координировать действия на нижнем уровне на основе решений, принимаемых на верхнем уровне или отсылать обработанные данные и статистику с нижнего уровня на верхний. 

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

Для коммуникации между слоями в ICS-средах обычно используются различные протоколы. SCADA-сервер, находящийся на верхнем уровне, общается с Полевыми контроллерами на среднем уровне при помощи протоколов DNP3 или Modbus. Полевые контроллеры взаимодействуют с Полевыми устройствами при помощи протоколов HART, Foundation Fieldbus и ProfiBus.

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

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

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

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

Риски, связанные с ICS-системами

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

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

• Ходили слухи, что в 1982 году ЦРУ внедрило вредоноса в газовую систему СССР в Сибири, что спровоцировало крупнейший неядерный взрыв (http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1455559/CIA-plot-led-to-huge-blast-in-Siberian-gas-pipeline.html)
• В марте 1997 года тинейджер из Массачусетса «уронил» Вустер (аэропорт Массачусетса) посредством вывода из строя распределенной телефонной системы, основной и запасной радиопередатчик и устройство печати, используемые для мониторинга хода полетов (http://www.cnn.com/TECH/computing/9803/18/juvenile.hacker/index.html)
• Весной 2000 года Витек Боден (Vitek Boden), недовольный австралийский инженер системы SCADA из компании Maroochy Water Services, намеренно спровоцировал разлив 800 тысяч литров сточных вод в местные парки, реки и даже на территорию отеля Hyatt Regency (http://csrc.nist.gov/groups/SMA/fisma/ics/documents/Maroochy-Water-Services-Case-Study_report.pdf)
• 25 января 2003 года червь SQL Slammer на 5 часов вывел из строя систему мониторинга безопасности атомной электростанции Davis-Besse в Огайо (http://www.securityfocus.com/news/6767)
• В 2007 году в лаборатории Idaho Falls National Laboratory в ходе тестирования генератора Aurora было продемонстрировано, насколько просто при помощи скрипта, написанного на Python, можно рассогласовать компоненты генератора и спровоцировать массовые физические разрушения (https://www.youtube.com/watch?v=fJyWngDco3g)
• В 2008 году польский инженер продемонстрировал риски, связанные с полевыми устройствами (в данном случае переключателями рельсовых направляющих), при использовании переделанного пульта управления телевизором для передачи команд в городскую железнодорожную систему, что спровоцировало сход с рельсов (https://www.wired.com/2008/01/polish-teen-hac/)
• В 2010 году произошла возможно самая широко известная атака на системы ICS на атомной электростанции Натанз в Иране. Вредонос, впоследствии получивший имя STUXNET, считался самым изощренным публичным вирусом, который был направлен на программируемые логические контроллеры и человеко-машинные интерфейсы, используемые в центрифугах для создания ядерных материалов, способных к расщеплению (https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/)
• В 2014 году неустановленный сталелитейный завод из Германии подтвердил факт кибератаки на ICS-сеть, которая не позволяла отключаться доменной печи корректным образом (https://www.wired.com/2015/01/german-steel-mill-hack-destruction/)
• 23 декабря 2015 года злоумышленникам удалось отключить не менее 7 подстанций, работающих под напряжением 110 кВ, и 23 подстанции, работающих под напряжением 35 кВ, на украинских предприятиях Прикарпатьеоблэнерго и Киевоблэнерго. Атака на системы SCADA этих предприятий оставила без электричества около 80 тысяч человек на 6 часов (http://www.theregister.co.uk/2016/01/15/malware_clearly_behind_ukraine_power_outage_sans_utility_expert_says/)

Хотя атаки, направленные на наведение хаоса и вывода из строя компонентов, наподобие вредоноса STUXNET на первый взгляд могут казаться простыми, когда речь заходит системах ICS нужно принимать во внимание следующее:

• Если злоумышленник сможет перехватить и модифицировать данные, передаваемые между Полевыми устройствами и Полевыми контроллерами, становится возможным передача поддельной информации человеко-машинным интерфейсам. Далее человеко-машинные интерфейсы, показывая неточные данные, провоцируют оператора к принятию неверных решений. Уязвимости, способствующие проведению атак типа «человек посередине» с возможностью модификации информации, должны быть на первом месте в списке критических проблем.
• Многие Полевые контроллеры не требуют аутентификации, принимая команды от любых систем сети. Используя утилиты наподобие Scapy, можно легко создавать пакеты протоколов Modbus или DNP3.
• Знания в области информационных технологий в сочетании с пониманием физики процессов могут быть использованы для создания особо изощренных спецэффектов, что в свою очередь может лечь в основу захватывающего голливудского сценария. Концепции подобного рода атак несомненно получат наивысшую оценку.