05.10.2010

Обзор инцидентов информационной безопасности АСУ ТП зарубежных государств

В этой статье опубликованы аналитические данные по уязвимостям в АСУ ТП.

По материалам Интернет-изданий за 2008-2010 гг.

Гарбук Сергей Владимирович
Комаров Андрей Андреевич
Салов Евгений Игоревич
НТЦ «Станкоинформзащита» (http://itdefence.ru)

1. Статистика уязвимостей программно-аппаратного обеспечения сектора АСУ ТП

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

За период с 2008 по 2010 год в элементах АСУ ТП, составляющих её программно-аппаратную базу, были обнаружены множественные уязвимости, которые могут привести к нарушению корректной работы технологического процесса и реализации угроз несанкционированного доступа к информации, обрабатываемой в:

  • системах диспетчерского управления и сбора данных (SCADA);
  • отдельных интерфейсах управления объектами автоматизации;
  • элементах телеметрической подсистемы и телемеханики;
  • прикладных приложениях для анализа производственных и технологических данных;
  • системах управления производством (MES-системы).

В настоящем аналитическом отчёте отдельно выделялись специфичные АСУ ТП уязвимости, наряду с векторами атак, уже нашедшими своё применение в отношении современных WEB-приложений, СУБД, компонентов операционных систем, стороннего прикладного ПО. Использование традиционных информационных технологий в элементах АСУ ТП является одной из причин низкого уровня защищённости большинства из них. Данный фактор позволяет злоумышленнику апробировать существующие знания в отношении элементов АСУ ТП, что говорит о существенной доступности эксплуатации уязвимостей по открытым источникам (подтверждается наличием афишированного способа эксплуатации в виде «эксплоита» или «Proof-of-Concept»). Время устранения уязвимости варьируется и было дополнительно изучено в ходе составления отчёта для уточнения возможного интервала пребывания скомпрометированной АСУ ТП или её элементов в аварийном состоянии.

Содержание отчёта было построено исключительно на общедоступных сведениях и фактах о случившихся инцидентах информационной безопасности АСУ ТП и опубликованных уязвимостях. Представленные уязвимости на данный момент не являются критическими в связи с выпуском обновлений безопасности для каждой из них. Дополнительным источником происхождения представленных инцидентов информационной безопасности являлись специализированные базы данных учёта инцидентов такого рода в секторе критически важных инфраструктур зарубежных государств:

  • RISI (The Repository of Industrial Security Incidents);
  • ISID (Industrial Security Incident Database).

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

1.1 Использованная методика анализа характеристик и свойств уязвимости

При составлении данного аналитического отчёта специалистами НТЦ «Станкоинформзащита» использовалась общая система оценки уязвимостей версии 2 (CVSS v2) [1], которая позволяет наиболее ёмко описать свойства уязвимости и соответствующие риски, которые она может за собой повлечь. CVSS v2 разбита на три группы описательных метрик: базовые, временные и метрики окружения.

Базовые метрики – описывают основные свойства уязвимости.

Временные метрики – описывают характеристики, изменяющиеся с течением времени, среда применения уязвимости (окружения) не влияет на их изменение.

Метрики окружения – свойства уязвимости, характерные определённой среде применения уязвимости.

К каждой из групп определены параметры, значения которых подсчитываются по специальной методике. После выставления соответствующих значений, результат вычисления градируется по шкале от 1 до 10, пропорциональной шкале от низкого уровня критичности до высокого.
Для тех уязвимостей, подсчёт показателей CVSS v2 которых не проводился, были проведены дополнительные описания с выставлением значений групп метрик  по сведениям информационно-аналитических ресурсов, зафиксировавших появление уязвимости (ленты уязвимостей «Bugtrack», ресурсы технической поддержки пользователей на официальных сайтах производителей программной продукции).

Пример:

Переполнение стека в продукте RealFlex Technologies Ltd. RealWin Server 2.0 системы SCADA [2].

Комплексный показатель базовых метрик CVSS v2: 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C).

Значения параметров показателя базовых метрик:

AV (вектор эксплуатации) – N (network, сетевой);
AC (сложность использования уязвимости) – L (low, низкая);
Au (необходимость прохождения процедуры проверки подлинности) – N (none, не требуется);
C (влияние уязвимости на конфиденциальность информации) – C (complete, полное раскрытие);
I (влияние уязвимости на целостность информации) – C (complete, полное нарушение);
A (влияние уязвимости на доступность информации) – C(complete, полное нарушение).

Коэффициенты значений параметров показателя базовых метрик (предопределены CVSS v2):

AV:N = 1.0;
AC:L = 0.71;
Au:N = 0.704;
C:C = 0.660;
I:C = 0.660;
A:C = 0.660.

Расчёт комплексного значения базовых метрик:

BaseScore = round_to_1_decimal(10 * AccessVector (1.0)
                * AccessComplexity (0.71)
                * Authentication (0.704)
                * ((ConfImpact (0.660) * ConfImpactBias (без учёта))
                + (IntegImpact (0.660)  * IntegImpactBias (без учёта))
                + (AvailImpact (0.660) *AvailImpactBias (без учёта)))) = 10.0

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

Были рассчитаны показатели групп временных метрик и метрик окружения. Названные группы являются дополнительными и предназначены для уточнения свойств уязвимости.

Расчёт комплексного значения временных метрик

TemporalScore = round_to_1_decimal(BaseScore*Exploitability *RemediationLevel*ReportConfidence)  

Расчёт комплексного значения метрик окружения

EnvironmentalScore = round_to_1_decimal((AdjustedTemporal+ (10 -  AdjustedTemporal)*CollateralDamagePotential)*TargetDistribution)
AdjustedTemporal = TemporalScore recomputed with the BaseScores Impact sub-equation replaced with the AdjustedImpact equation
AdjustedImpact = min(10,10.41*(1-(1-ConfImpact*ConfReq)*(1-IntegImpact*IntegReq)

                 *(1-AvailImpact*AvailReq)))

1.2 Использованная методика оценки последствий реализации угроз НСД АСУ ТП

После определения свойств уязвимостей в программных продуктах элементов АСУ ТП проводился сравнительный анализ угроз реализации НСД в отношении АСУ ТП с использованием:

  • организации апробации уязвимости в стендовых условиях лаборатории;
  • анализа категории безопасности (КБ, SC) и соответствующего суммарного ущерба (Impact), который может быть нанесён информационной системе на примере информационных систем федерального уровня зарубежных государств в соответствии с документом FIPS 199 «Standards for Security Categorization of Federal Information and Information Systems» [3].   

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

Значения показателей нанесённого ущерба:

  • низкий уровень ущерба (НИЗКИЙ, раскрытие конфиденциальности, нарушение целостности и доступности влекут несущественные, ограниченные или предотвратимые последствия);
  • средний уровень ущерба (СРЕДНИЙ, раскрытие конфиденциальности, нарушение целостности и доступности влекут существенные негативные последствия в отношении деятельности Владельца информационной системы, её пользовательских активов);
  • высокий уровень ущерба (ВЫСОКИЙ, раскрытие конфиденциальности, нарушение целостности и доступности влекут катастрофические последствия).

Пример FIPS 199: система диспетчеризации и распределения электроэнергии военного формирования.

Описание:

Система SCADA электроэнергетической подстанции, терминалы накопления данных о распределении энергии, разнесены по территории. Система SCADA обрабатывает как информацию со стороны терминалов накопления данных (показатели уровня энергии, количественная оценка, информация об отказах), так и обычную служебную информацию. 

Категории безопасности:

КБ данные терминала = {(конфиденциальность, НЕ ОПРЕДЕЛЁН), (целостность, ВЫСОКИЙ), (доступность,  ВЫСОКИЙ)},
КБ служебная информация = {(конфиденциальность, НИЗКИЙ), (целостность, НИЗКИЙ), (доступность, НИЗКИЙ)}.
Результирующая категория безопасности информационной системы:
КБ система SCADA = {(конфиденциальность, НИЗКИЙ), (целостность, ВЫСОКИЙ), (доступность, ВЫСОКИЙ)}.
Владельцем информационной системы может быть изменён любой из показателей категории, в соответствии с угрозой раскрытия данных о ходе технологического процесса, особенностей архитектуры технологической сети критически важного объекта, входящего в состав ключевых инфраструктур зарубежного государства, показатель нанесения ущерба в отношении конфиденциальности системы SCADA был изменён на «СРЕДНИЙ»:
КБ система SCADA = {(конфиденциальность, СРЕДНИЙ), (целостность, ВЫСОКИЙ), (доступность, ВЫСОКИЙ)}.
Данная результирующая категория системы диспетчеризации была взята за основу при описании возможных последствий реализации угроз НСД к информации, обрабатываемой в АСУ ТП.

Таблица 1. Статистика обнаруженных уязвимостей в элементах АСУ ТП (2008-2010 г.)

Название продукта

Тип уязвимости

Описание уязвимости

Дополнения

DATAC RealWin 2.0
(система диспетчеризации) [4]

Исполнение произвольного кода авторизированным пользователем

Переполнение стека при обработке специально сформированного FC_INFOTAG/SET_CONTROL пакета, направленного на приём в TCP-порт 910 удалённой системы

Дата обнаружения – 2008 год. Доступен полнофункциональный эксплуатирующий код.

GE Fanuc Proficy Information Portal 2.6
(WEB-приложения для анализа производственных данных) [5]

Загрузка и исполнение произвольных файлов

Аутентифицированный пользователь может загрузить любой произвольный файл на сервер, используя сценарий «Add WebSource», в последствии исполнить его путём обращения к WEB-серверу. Данная уязвимость может привести к несанкционированному размещению на WEB-сервере программных «закладок» класса «WEB-shell»

Дата обнаружения – 2008 год. Уязвимость вызвана из-за небезопасного использования Java RMI вызова к указанному сценарию WEB-приложения, который позволяет задать имя файла и каталог, куда будет размещён файл.

ABB PCU400 4.4-4.6
(блок связи) [6]

Неавторизированное исполнение произвольного кода

Удалённое переполнение буфера в модуле обработке протоколов IEC60870-5-101, IEC60870-5-104

Дата обнаружения – 2008 год. ABB PCU 400 является FEP-сервером системы диспетчеризации ABB SCADA, который отвечает за управление подсистемой телеметрических устройств.

GE Fanuc Cimplicity 6.1
(система диспетчеризации) [7]

Неавторизированное исполнение произвольного кода

Удалённое переполнение кучи, которое может эксплуатироваться удалённым злоумышленником при доступности системы «из вне»

Дата обнаружения – 2008 год. На 2007-2008 год данный продукт был единственным, поддерживающим интеграцию с оборудованием ЧПУ семейства GE Fanuc.

AREVA e-terrahabitat
(система диспетчеризации) [8]

Множественные уязвимости, приводящие к отказу в обслуживании, повышению привилегий

Успешная эксплуатация уязвимости выводит из строя WEB-сервер WebFGServer, платформу NETIO. Повышение привилегий в среде WEB-сервера и приложения MLF

Дата обнаружения – 2009 год. Активно используется на малых объектах нефтегазового сектора.

OSISoft PI Server
(OPC-сервер) [9]

Раскрытие критичных данных для доступа к базе данных

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

Дата обнаружения – 2009 год. Для устранения уязвимости рекомендуется использовать IPSec между клиентами сети и PI Server

CitectSCADA
(система диспетчеризации) [10]

Неавторизированное исполнение произвольного кода

При наличии запущенного ODBC-сервера (TCP-порт 20222) удалённый злоумышленник может скомпрометировать целевую систему

Дата обнаружения – 2008 год. Для устранения уязвимости рекомендуется не использовать службу ODBC

Контроллеры Rockwell Automation (Allen Bradley) Micrologix 1100/1400
(удалённый терминал) [11]

Отказ в обслуживании, несанкционированный доступ с возможностью повышения привилегий

Множественные уязвимости, приводящие к возможности несанкционированной модификации PLC, опознания сторонних устройств

Дата обнаружения – 2010 год. Контроллеры Micrologix являются одной из самой распространённых платформ для систем управления с программируемой логикой

WonderWare SiteLink version 2.0,
WonderWare InTouch version 8.0
(система диспетчеризации) [12]

Отказ в обслуживании

Эксплуатация уязвимости приводит к внештатному нарушению корректной работы системы и её отключению.

Дата обнаружения – 2008 год. На данный момент доступна 10 версия системы. Системы Intouch являются одними из самых распространённых систем SCADA в США.

Таблица 2. Комплексные значения метрик оценки свойств уязвимостей с использованием CVSS v.2

Уязвимость

Базовые метрики

Временные метрики

Метрики окружения

ABB PCU400 4.4-4.6 Remote Buffer Overflow

10.0

8.3

6.6

AREVA e-terrahabitat / e-terraplatform Multiple Vulnerabilities

3.3

2.7

3.7

CitectSCADA ODBC service vulnerability

10.0

8.3

6.6

GE Fanuc Proficy Information Portal 2.6 Arbitrary File Upload and Execution

7.0

5.8

5.3

GE Fanuc Proficy Information Portal 2.6 Authentication Vulnerability

4.7

3.9

4.3

GE Fanuc Cimplicity 6.1 Heap Overflow

10.0

8.3

6.6

OSISoft PI Server Authentication Weakness

4.7

4.9

4.3

RealWin SCADA server FC_INFOTAG/SET_CONTROL buffer overflow

10.0

8.3

6.6

Rockwell Automation (Allen Bradley) Multiple Vulnerabilities in Micrologix 1100 & 1400 Series Controllers

10.0

8.3

6.6

Wonderware SuiteLink Denial of Service vulnerability

2.3

1.9

3.2

Таблица 3. Уязвимости и программные бреши, обнаруженные специалистами НТЦ «Станкоинформзащита»

Название продукта

Тип уязвимости

Описание уязвимости

Дополнения

Siemens WinCC

Ошибка конфигурации

При изменении пароля в приложениях WinCCAdmin/WinCCConnect дальнейшая работа с базой данных MSSQL становится недоступной, проект технологического процесса будет удалён и в последствии станет недоступен

Модераторы технического сообщества SIEMENS признали данный факт, разработанные ими рекомендации направлены на сохранение штатного пароля в неизменном виде.

TF3400

Ошибка конфигурации

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

Производитель уведомлён о наличии уязвимости.

Контроллеры TF3000

Ошибка конфигурации

Возможность неавторизированного съема информации о запущенных процессах в ОС контроллера

Производитель уведомлён о наличии уязвимости. Исправление уязвимости на данный момент отсутствует.

Netbiter® webSCADA

Множественные уязвимости безопасности

Возможность локального чтения файлов (класс «Local File Disclosure»), неавторизированное снятие данных об имеюшихся в системе пользователях, возможность загрузки злонамеренного кода («web-shell) для выполнения неавторизированного кода на сервере.

Производитель уведомлён о наличии уязвимости ([STANKOINFORMZASCHITA-10-01] Netbiter® webSCADA – множественные уязвимости - http://itdefence.ru/content/advisory/scada/10_01/ ). Исправление уязвимости на данный момент отсутствует.

ITS SCADA

SQL-инъекция в модуле авторизации пользователя для доступа в систему

Возможность неавторизированного чтения таблиц «RTUinfo», «Alarms», «BMWInfo», «dtproperties», «FlowData», «LSHistory», «Users» и др., раскрытие информации.

Производитель уведомлён о наличии уязвимости ([STANKOINFORMZASCHITA-10-02] ITS SCADA – Обход авторизации - http://itdefence.ru/content/advisory/scada/10_02/ ). Исправление уязвимости на данный момент отсутствует.

Broadwin SCADA

Blind SQL-инъекция в модуле авторизации пользователя для доступа в систему

Возможность неавторизированного чтения таблиц «bwdb_access», «bwdbbackup_excel», «bwdbexport_excel», «bwdnode_access», «bwpdata_access» и др. , раскрытие информации для последующей компрометации системы.

Производитель уведомлён о наличии уязвимости ([STANKOINFORMZASCHITA-10-03] Broadwin SCADA - Blind SQL-injection - http://itdefence.ru/content/advisory/scada/10_03/ ). Исправление уязвимости на данный момент отсутствует.

ICSCADA (Outlaw Automation)

Blind SQL-инъекция в модуле авторизации пользователя для доступа в систему

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

Используется в области газодобывающей промышленности. Производитель уведомлён о наличии уязвимости ([STANKOINFORMZASCHITA-10-04] ICSCADA (Outlaw Automation) – Blind SQL-injection - http://itdefence.ru/content/advisory/scada/10_04/ ). Исправление уязвимости на данный момент отсутствует.

InduSoft SCADA

Обход директорий в WEB-сервере CET системы SCADA (Indusoft Web Studio)

Возможность неавторизированного чтения файлов путём обхода ограничений на просмотр файлов директорий и их содержимого путём специально сформированного GET-запроса.

Производитель уведомлён о наличии уязвимости (подробности уязвимости пока не афишированы). Исправление уязвимости на данный момент отсутствует.

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

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

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

2. Доступность сведений для успешной эксплуатации уязвимостей

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

Таблица 4. Эксплуатирующий код в составе свободно распространяющихся пакетов

Программный продукт

Тип уязвимости

Включение в состав

Ограничения

CitectSCADA

Неавторизированное исполнение кода

Metasploit Project

«Эксплоит» доступен под платформы Windows XP SP2/SP3, Windows 98 SE, Windows 2003 Server SP1

Wonderware Suitelink 2.0

Отказ в обслуживании

Metasploit Project

Требует наличие открытого TCP-порта 5413

RealWin SCADA Server 2.0

Неавторизированное исполнение кода

Metasploit Project

«Эксплоит» доступен под платформы Windows XP SP2 (EN/ES), Windows 2000 SP4 (EN/ES)

GE Fanuc Real Time Information Portal 2.6

Неавторизированное изменение данных

Metasploit Project

Отсутствуют, существует отдельный «эксплоит» на языке Python

Таблица 5. Примеры эксплуатирующего кода в составе коммерчески распространяемых пакетов

Программный продукт

Тип уязвимости

Включение в состав

Modicon PLC

Использование паролей по умолчанию

Nessus (Tenable),
SCADA-Аудитор (НТЦ “Станкоинформзащита»)

Modicon PLC HTTP Server

Использование паролей по умолчанию

Nessus (Teenable),
SCADA-Аудитор

Sisco OSI

Отказ в обслуживании

Nessus (Teenable),
SCADA-Аудитор

Netbiter

Неавторизированное исполнение кода

Nessus (Teenable),
SCADA-Аудитор

Automated Solutions Modbus TCP Slave

Переполнение кучи в ActiveX-компоненте

Nessus (Teenable),
SCADA-Аудитор

Livedata

Неавторизированное исполнение кода

Nessus (Teenable),
SCADA-Аудитор

Takebishi Electric DeviceXPlorer OPC Server

Неавторизированное исполнение кода

Nessus (Teenable),
SCADA-Аудитор

Iconics DlgWrapper

Переполнение буфера в ActiveX-компоненте

Nessus (Teenable),
SCADA-Аудитор

TF3400

Обход авторизации

SCADA-Аудитор

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

Таблица 6. Время устранения уязвимости в программных пакетах систем диспетчеризации АСУ ТП

Программный продукт

Тип уязвимости

Дата уведомления

Дата  устранения

Производитель

CIMPLICITY 6.1

Неавторизированное выполнение кода

25.01.2008

1.11.2008

GE Fanuc

CitectSCADA 6.0-7.0

Неавторизированное выполнение кода

11.06.2008

9.09.2008

Citect

WonderWare SuiteLink 2.0

Отказ в обслуживании

30.01.2008

28.04.2008

Wonderware

Интервал между уведомлением разработчика (в некоторых случаях данное событие совпадало или заменялось на публикацию описания уязвимости в открытые источники) и выпуском обновления безопасности для исправления уязвимости составляет от 3 до 10 месяцев. Наряду с этим,  практически каждая спецификация устройств или элементов, входящих в состав систем диспетчеризации АСУ ТП, сопровождается показателями надёжности MTTR, MTTF, MTBF [13]:

MTTR (Mean Time To Repair) – среднее время восстановления;
MTTF (Mean Time To Failure) –  среднее время работы устройства или системы до наступления отказа любого вида;
MTBF (Mean Time Between Failures)  – среднее время между двумя последовательными отказами.

Показатели надёжности системы диспетчеризации АСУ ТП

Использование усреднённых показателей надёжности АСУ ТП различных производителей фиксирует следующие значения представленных показателей:

MTTR = 12 часов;
MTBF = 60 000 часов;
MTTF = MTBF – MTTR = 60 000 – 12 = 59 988 часов.

Коэффициент готовности такой системы:

Ai (%) = 100 * MTBF/(MTBF+MTTR) = 100 * 60000/60012 = 99,98%.

Показатели надёжности системы диспетчеризации АСУ ТП с имеющейся уязвимостью

Используя усреднённое время выпуска обновления безопасности систем диспетчеризации АСУ ТП (SCADA), представленное в Таблице 5 (5,3 месяца), можно понять, что MTTR такой системы будет существенно больше при возникновении ситуации обнаружения в ней уязвимостей в программно-аппаратном обеспечении, реализация которой будет обозначаться в качестве аварийно-ремонтной ситуации или временем для восстановления безопасной работы:

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

3. Распространение специального злонамеренного кода в секторе АСУ ТП

Отдельной угрозой, частично использующей штатные методы для исполнения, является распространение злонамеренного кода для кражи критически важных данных о проектах технологических процессов и нарушения их корректной работы, подтверждение чему является факт распространения вредоносного кода «Rootkit.TmpHider» и «Scope.Rookit.TmpHider.2» [14]. Многие популярные системы диспетчеризации (SCADA) базируются на платформе ОС Microsoft Windows, поэтому данный факт указывает на необходимость обеспечения информационной безопасности операционной системы, на которую устанавливается прикладное программное обеспечение.

Названные образцы вредоносного кода использовали уязвимость MS10-046 [15] (http://www.microsoft.com/technet/security/bulletin/MS10-046.mspx) в Windows Shell, позволяющей неавторизированно исполнить произвольный код с помощью отображения специально сформированного ярлыка оболочки ОС Microsoft Windows. Основным методом распространения  являлось применение отделяемых носителей (USB-flash, Compact-Flash, сторонние съёмные носители информации), которые могут использовать Операторы для управления проектами технологических процессов, обмена информацией между собой.

В качестве полезной нагрузки зловреды использовали сценарий для СУБД MSSQL, с которой может быть сопряжена среда Simatic WinCC/STEP7 и модифицированную подключаемую библиотеку, в которой содержались основные функции для работы с PLC:

4. Статистика инцидентов информационной безопасности сектора АСУ ТП

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

Таблица 7. Инциденты информационной безопасности (2008-2010) сектора АСУ ТП

Объект

Инцидент

Дата

Блок 2 ядерной станции «Hatch» (штат Джорджиа, США) [16]

Внештатное аварийное выключение на 48 часов после установки обновления программного обеспечения (похожий инцидент случился в 2006 году на ядерной станции «Browns Ferry» из-за нештатного сбоя программируемого логического контроллера при получении аномального выходного сетевого трафика из производственной сети)

7 марта 2008 года

Корпорация Tennessee Valley Authority (TVA)  (в ведомости данной энергетической корпорации находятся 11 угольных станций, 8 ТЭС, 3 ядерных станции, 29 ГЭС США) [17]

Проверка регуляторов (GAO, HHS) выявила порядка 2000 уязвимостей разной степени критичности. Среди брешей в безопасности были выявлены сегменты производственной сети, подключённые к Интернет, множественные уязвимости прикладного ПО, отсутствие обновлений безопасности, ошибки в проектировании архитектуры сети и каналов обмена данными

май 2008 года

Центр полётного планирования Федерального управления гражданской авиации США [18]

Диспетчерские трех десятков американских аэропортов выведены из строя в результате компьютерного сбоя в центре полётного планирования.

26 августа 2008 года

Газодобывающие компании США (Marathon Oil, ExxonMobil, ConocoPhillips) [19]

Силовыми структурами США зафиксированы многочисленные проникновения в АС ведущих газодобывающих компаний.

май 2008 года

Сбой движения поездов немецких железных дорог (DB) [20]

Компьютерный сбой привёл в приостановке системы бронирования и продажи билетов, диспетчеризация движения поездов осуществлялась «ручным» образом

14 января 2009

Электроэнергетическая сеть США [21]

Силовыми структурами США зафиксировано проникновение в электроэнергетическую сеть и размещения в ней программных «закладок», направленных на внештатный останов её функциональных элементов и нарушение корректной работы

апрель 2009 года

Энергетическая компания LCRA (Lower Colorado River Authority) [22]

Специалистами LCRA зафиксировано свыше 4800 попыток получения доступа к их компьютерной системе. В настоящее время LCRA обслуживает более 1 миллиона людей в штате Техас.

5 апреля 2010 года

Литература и использованные информационные источники:

  1. A Complete Guide to the Common Vulnerability Scoring SystemVersion 2.0  (http://www.first.org/cvss/cvss-guide.html);
  2. High Impact, Low Frequency Risks to the NA Power Grid (NERC);
  3. US-CERT Vulnerability Note VU#976484 «RealFlex RealWin buffer overflow» (http://www.kb.cert.org/vuls/id/976484);
  4. FIPS 199, Feb 2004, Standards for Security Categorization of Federal Information and Information Systems;
  5. DATAC RealWin SCADA Software PreaAuth (Exploit) (http://www.securiteam.com/windowsntfocus/5UP0W00PFW.html);
  6. GE Fanuc Proficy Information Portal Vulnerabilities (http://www.securiteam.com/securitynews/5WP0O2KN5E.html);
  7. C4 Security Advisory - ABB PCU400 4.4-4.6 Remote Buffer Overflow (http://www.scada-security.com/vulnerabilities/abb1.html);
  8. C4 Security Advisory - GE Fanuc Cimplicity 6.1 Heap Overflow (http://www.scada-security.com/vulnerabilities/gefanuc2.html);
  9. C4 SCADA Security Advisory – AREVA e-terrahabitat / e-terraplatform Multiple Vulnerabilities (http://www.scada-security.com/vulnerabilities/areva1.html);
  10. C4 SCADA Security Advisory – OSISoft PI Server Authentication Weakness (http://www.scada-security.com/vulnerabilities/osisoft1.html);
  11. US-CERT Vulnerability Note VU#476345 «Citect CitectSCADA ODBC service buffer overflow» (http://www.kb.cert.org/vuls/id/476345);
  12. C4 SCADA Security Advisory – Rockwell Automation (Allen Bradley) Multiple Vulnerabilities in Micrologix 1100 & 1400 Series Controllers  (http://www.scada-security.com/vulnerabilities/rockwellautomation1.html);
  13. WonderWare SiteLink Denial of Service (Exploit)  (http://www.securiteam.com/exploits/5CP0N0APFY.html);
  14. Интегральные уровни безопасности в соответствии со стандартами МЭК 61508 и 61511 и анализ их связи с техническим обслуживанием («Современные технологии автоматизации», Глизенте Ландрини);
  15. ICSA-10-201-01—USB MALWARE TARGETING SIEMENS CONTROL SOFTWARE;
  16. Microsoft Security Advisory (2286198) «Vulnerability in Windows Shell Could Allow Remote Code Execution» (http://www.microsoft.com/technet/security/advisory/2286198.mspx);
  17. «Cyber Incident Blamed for Nuclear PowerPlant Shutdown» (Washingtonpost, Brian Krebs, 5 июня 2008 года);
  18. «TVA Needs to Address Weaknesses in Control Systems and Networks» (http://www.gao.gov/new.items/d08526.pdf);
  19. «Аэропорты в США пострадали от сбоя сети» (BBC, 26 августа 2008 года)
  20. «Hackers Targeted Oil Companies for Oil-Location Data» (http://www.wired.com/threatlevel/2010/01/hack-for-oil/, Kim Zetter, 26 января 2010 года);
  21. «Компьютерный сбой парализовал немецкие железные дороги на полдня» (Travel.ru, 16 января 2009 года);
  22. «'Smart Grid' may be vulnerable to hackers» (CNN, Jeanne Meserve, 21 марта 2009 года);
  23. «Texas utility target of cyberattack» (CHRON, 6 апреля 2010 года);
  24. Страница российской рабочей группы MESA International (http://www.mesarussia.ru/en/);
  25. Стандарт МЭК 61508. Функциональная безопасность электрических, электронных, программируемых электронных систем, связанных с безопасностью;
  26. Стандарт МЭК 61511. Системы обеспечения безопасности для перерабатывающих отраслей промышленности;
  27. Функциональная безопасность систем, связанных с обеспечением безопасности: руководство по проектированию и обслуживанию. – GM International S.r.l., 2008. – 425 стр.;
  28. Руководящий документ. Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации (Решение председателя Гостехкомиссии Россииот 30 марта 1992 года);
  29. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения (Решение председателя Гостехкомиссии России от 30 марта 1992 года);
  30. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации (Решение председателя Гостехкомиссии  России от 30 марта 1992 года);
  31. ГОСТ 24.104-85. Автоматизированные системы управления. Общие требования;
  32. SCADA: Supervisory Control and Data Acquisition, 4th Edition (Stuart A. Boyer, 2010 год);
  33. The Center for SCADA Security (sandia.gov);
  34. CPNI, Centre for Protection of National Infrastructure (cpni.gov.uk);
  35. Материалы SANS Process Control & SCADA Security Summit 2010;
  36. Проектирование АСУТП. Методическое пособие (Нестеров А.Л., 2010 год);
  37. Автоматизация производственных процессов в химической промышленности (Голубятников В.А., Шувалов В.В., "Химия", 1985 год);
  38. Справочник инженера по АСУТП. Проектирование и разработка (Ю. Н. Федоров, Инфра-Инженерия, 2008 год);
  39. Сбор данных в системах контроля и управления. Практическое руководство. (Парк Дж., Маккей С., серия  "Безопасность и системы промышленной автоматизации. Опыт практического применения");
  40. Информационные технологии систем управления технологическими процессами (Маргарита Благовещенская, Леонид Злобин, Высшая школа, 2005 год);
  41. "КИП Инфо", Автоматизированные системы управления в нефтегазовом комплексе;
  42. Насколько «дыра» широка? (С.Гордейчик, Positive Technologies, «Открытые системы», 2006 год);
  43. Особенности обеспечения информационной безопасности систем SCADA (Гарбук С.В., Комаров А.А., РусКрипто'2010).
или введите имя

CAPTCHA
Страницы: 1  2  
lifeofit
05-10-2010 06:25:30
мелочь, опечатка. автор Nessus = Tenable Network Security (одна "e")
0 |
Евгений Ваганович
05-10-2010 16:36:30
По сути - назовите хотя бы один случай отказа технологического контроллера (либо останов объекта путем выдачи команд контроллеру), вызванный "извне" вирусом, который имел место на практике? На верхний уровнь, собственно, можно пока и наплевать - ну зависла машина, удален проект с винта - все это очень быстро восстанавливается (при наличии прямых рук), к тому же вся логика управления обрабатывается в контроллере - система ПАЗ в этом случает продолжит функционировать в обычном режиме. Другое дело - это членовредительство, когда люди, имеющие доступ к проекту, сознательно создают "бэкдоры" в СКАДЕ - но это уже совсем другая история.
0 |
05-10-2010 19:03:14
Отвечаю по сути - один из отказов, случившийся в ситуации отказа контроллера (контроллеров), произошёл на ядерной станции «Hatch» (штат Джорджиа, США), по причине, описанной в отчёте. Никаких других примеров я привести не могу, потому что эта информация - дана по открытым источникам, по ясным причинам. По поводу "вируса" - есть конкретные примеры и объекты, инфраструктра которых доступна "из вне", соответственно, это указывает на возможность опознания реальной технологической сети и её элементов по различным признакам, в том числе косвенным - распространение вредоносного кода в отношении её осуществимо. Касательно вредоносного кода у нас есть "PoC"-варианты, которые в последствии будут описаны в наших работах под конкретные контроллеры (вариант родился после реверсинга прошивок соответствующих контроллеров). удален проект с винта - все это очень быстро восстанавливается (при наличии прямых рук) Готов поспорить, насколько быстро это "всё восстанавливается", даже при понимании природы инцидента. В лабораторных испытаниях удаления проекта и нарушение работы нескольких элементов АСУ ТП на базе TECON у инженера заняло около 25-40 минут, при плотном взаимодействии со специалистами по ИБ, которые поясняли суть проблемы.
0 |
Евгений Ваганович
06-10-2010 18:48:40
один из отказов, случившийся в ситуации отказа контроллера (контроллеров), произошёл на ядерной станции «Hatch» (штат Джорджиа, США), по причине, описанной в отчётето есть это Внештатное аварийное выключение на 48 часов после установки обновления программного обеспечения (похожий инцидент случился в 2006 году на ядерной станции «Browns Ferry» из-за нештатного сбоя программируемого логического контроллера при получении аномального выходного сетевого трафика из производственной сети) все это вилами по воде писано- как на 48 часов может произойти сбой? что все это время делали люди? перезаливка ПО в контроллер занимает от силы 5 минут (еще 5 минут на поиск последнего бэкапа) - вероятно, причина опять же бла не в контроллере, а на верхнем уровне - HMI. То есть приходим опять же к началу - нет ни одного случая вредоносного вмешательства вируса в ПО контроллера В лабораторных испытаниях удаления проекта и нарушение работы нескольких элементов АСУ ТП на базе TECON у инженера заняло около 25-40 минут, при плотном взаимодействии со специалистами по ИБ, которые поясняли суть проблемы.25-40 минут - это очень быстро по меркам АСУ. не?
0 |
06-10-2010 23:04:54
HMI - это "морда", она трафик никакой не может обрабатывать по определению. Конкретный инцидент произошёл о том, что именно контроллер вышел из строя, некорректно обработав соответствующие потоки служебного трафика. "Вилами по воде" - пишите Вы сейчас, данная информация - носит открытый характер и никто её не придумывал. В статье не упомянуто ни одного намёка на то, что кто-то собирается разрабатывать аппаратно зависимый код на контроллеры - тем не менее такая возможность существует, я об этом уже писал. Спорить с Вами о том, что было впервые и "было или не было" не вижу смысла, моя задача - описать конкретный инцидент, разработать способы выявления данного типа уязвимостей, если они имеются в продуктах, с какими сталкиваемся мы, затем - разработать рекомендации для их устранения. В этой связи, то, что делали "люди" - нас не волнует, мы занимаемся не социальными и кадровыми вопросами или организацией труда на предприятии.
0 |
Евгений Ваганович
07-10-2010 10:31:38
HMI - это "морда", она трафик никакой не может обрабатывать по определениюк вашему сведению, контроллер тоже не обрабатывает трафик. И если уж говорить про "обработку трафика", то ХМИ куда ближе к этому определению, чем контроллер Конкретный инцидент произошёл о том, что именно контроллер вышел из строя, некорректно обработав соответствующие потоки служебного трафикана 99% это кривизна рук программистов - элементарное несоответствие типов/значений переменных/регистров тем не менее такая возможность существуетсуществование возможности - это слишком неопределенно. Ведь есть вероятная возможность взлома AES - вот тока надо найти дыры в алгоритме - но пока этого не сделано, но никто не отрицает, что потенциалььная возможность есть В этой связи, то, что делали "люди" - нас не волнует, мы занимаемся не социальными и кадровыми вопросами или организацией труда на предприятиинадо отделять вопросы криво разработанного проекта от конкретных уязвимостей - и классифицировать уже исходя из этого.
0 |
07-10-2010 14:30:01
Ну тут мне уже точно будет нечего сказать, если на то пошло к вашему сведению, контроллер тоже не обрабатывает трафик. И если уж говорить про "обработку трафика", то ХМИ куда ближе к этому определению, чем контроллер Задачи контроллеров очевидны - "выполнять" и "отсылать". Обработкой трафика "морда" не может заниматься по умолчанию, это вывод и интерпретация соответствующей информации, в рамки интерфейса, интуитивно доступному пользователю, собственно, почему он и называется, к Вашему сведению, человеко-машинный интерфейс, даже требования к этим вещам пишут, составляют требования к эргономике и так далее. В этой связи, именно по этому HMI строится на базе WEB-технологий и очень "бажно", либо это отдельное приложение, которое обращается к БД, где собственно накопленные данные хранятся и в том числе обрабатываются. Простые истины, не так ли? Примеры: Citect SCADA, INDAS SCADA, продукты и оборудование GE FANUC, SIEMENS. на 99% это кривизна рук программистов - элементарное несоответствие типов/значений переменных/регистров Мне кивнуть положительно или следует привести пример, что не только в этой сфере это имеет место быть ?
0 |
Евгений Ваганович
07-10-2010 19:18:06
Задачи контроллеров очевидны - "выполнять" и "отсылать"задачи контроллеров: выполнять свой алгоритм, отсылать ЗАПРАШИВАЕМЫЕ данные (как правило, если исключить межконтроллерное взаимодействие) HMI, и выполнять команды с HMI. То бишь просто "отсылкой" контроллер не занимается - и это очень важно для понимания сути предмета Обработкой трафика "морда" не может заниматься по умолчаниюя говорил про то, что понятие "обработки трафика" не применимо к АСУ и если уж и притягивать это понятие к АСУТП, то наиболее корректная область (не отдающая полным маразмом) - это обработка трафика системами HMI (то бишь отправка команд контроллеру и обработка полученных результатов в виде соответствующей анимации на дисплее и прочего. Базы данных тут не рассматриваем т.к. к базам тем более не подойдет описание "обработки трафика"). надеюсь на этом закончим с бредом про "обработку трафика"? и напоследок по этому моменту: либо это отдельное приложение, которое обращается к БДHMI обращается к БД практически только в единственном случае - при необходимости вывести на дисплей оператору архивную инфу (тренды параметров, журнал сигнализаций и т.д.). Но можно сделать и так: через спец драйвер/спец.ПО в базу кладутся данные с контроллера, а хми их оттуда вытягивает для визуализации оператору - но это уж точно буквальное соответствие фразе "вырезать гланды через ж..у" Примеры: Citect SCADA, INDAS SCADA, продукты и оборудование GE FANUC, SIEMENSвопрос на засыпку (гугл Вам в помощь): назовите самые распространенные ПО HMI в России? из вышеперечисленного только семён (wincc) в них входит Мне кивнуть положительно или следует привести пример, что не только в этой сфере это имеет место быть ?я ж писал - вам нужно просто было проклассифицировать ошибки в рамках ошибок в базовом ПО и в проектах на базе этого ПО
0 |
07-10-2010 20:27:36
Похоже мы говорим об одном и том же, это всё ясно прекрасно. задачи контроллеров: выполнять свой алгоритм, отсылать ЗАПРАШИВАЕМЫЕ данные (как правило, если исключить межконтроллерное взаимодействие) HMI, и выполнять команды с HMI. То бишь просто "отсылкой" контроллер не занимается - и это очень важно для понимания сути предмета Вам и написали, "выполнять" и "отсылать" - наряду с выполнением функций телеметрирования. я говорил про то, что понятие "обработки трафика" не применимо к АСУ и если уж и притягивать это понятие к АСУТП, то наиболее корректная область (не отдающая полным маразмом) - это обработка трафика системами HMI (то бишь отправка команд контроллеру и обработка полученных результатов в виде соответствующей анимации на дисплее и прочего. Базы данных тут не рассматриваем т.к. к базам тем более не подойдет описание "обработки трафика"). надеюсь на этом закончим с бредом про "обработку трафика"? и напоследок по этому моменту: Но можно сделать и так: через спец драйвер/спец.ПО в базу кладутся данные с контроллера, а хми их оттуда вытягивает для визуализации оператору - но это уж точно буквальное соответствие фразе "вырезать гланды через ж..у" Конечно, дык вот анимация на дисплее - это не обработка трафика, это вывод результатов знаний, которые были накоплены после его приёма. Чтобы не быть голословный вид - изучите, как работают SCADA известных брендов, на "скрипт" они ничего не принимают, никакого сетевого трафика им не шлётся на "морду", поэтому вы упорно пишите бред, не приводя никаких аргументов. В данном отчёте не освящался ни один отечественный продукт из идеалогических соображений, надеюсь, понятных Вам. В ближайшем будущем мы опубликуем несколько уведомлений безопасности по отечественному сегменту с подтверждением получения ответа от производителя.
0 |
07-10-2010 20:28:08
я ж писал - вам нужно просто было проклассифицировать ошибки в рамках ошибок в базовом ПО и в проектах на базе этого ПО Если Вы не поняли, мы занимается только выявлением и анализом защищённости ПО элементов АСУ ТП, что такое "базовое ПО" - мне непонятно. Устройство проектов на базе этого ПО - задача специалистов, которые проектируют непосредственно саму АСУ, это их компетенция, которая к нам не относится.
0 |
07-10-2010 14:30:19
существование возможности - это слишком неопределенно. Ведь есть вероятная возможность взлома AES - вот тока надо найти дыры в алгоритме - но пока этого не сделано, но никто не отрицает, что потенциалььная возможность есть Ну дык мы опишем, не торопите события, комментарии же не будем стирать, чтобы забрать слова обратно свои, возможность такая есть - следовательно вектор атаки имеется. Насколько его Exploitability сложно или доступно, или очевидно - другой вопрос. надо отделять вопросы криво разработанного проекта от конкретных уязвимостей - и классифицировать уже исходя из этого. Мы это сделали, в этой связи в отчёте нигде не идёт речи об организационных мерах или каких-либо неладностях с вопросами человеческого фактора в звене предпроектной работы, ввода в эксплуатацию, эксплуатации, это совершенно не наш вопрос. Мы говорим только об уязвимостях в ПО элементов АСУ ТП.
0 |
Евгений Ваганович
07-10-2010 19:24:23
Мы это сделалиМы говорим только об уязвимостях в ПО элементов АСУ ТП.это Вы так думали, пока я в комментах не стал заявлять, что ряд описанных в статье уязвимостей совсем другого рода (вспоминаем мои фразы про студентов) ЗЫ - капчо шикарное - 77033
0 |
07-10-2010 20:30:16
Не устанавливайте такой эгоистичной причинно-следственной связи, всё совсем не так. Вроде бы несколько раз было сказано, даже написано в отчёте, - уязвимости в ПО элементов АСУ ТП, про уязвимости "другого рода" - это к Вам скорее, не к нам
0 |
05-10-2010 19:04:19
система ПАЗ в этом случает продолжит функционировать в обычном режиме На приведённом примере (рисунке) был несанкционированно удалён технологический проект, при этом ПАЗ не выдала ни одного уведомления (для неё - это оказалось легитимной операцией), хотя такие операции может (должен) выполнять только супервайзер. Вендора ПО и оборудование - могу сказать только лично в закрытой переписке. Другое дело - это членовредительство, когда люди, имеющие доступ к проекту, сознательно создают "бэкдоры" в СКАДЕ - но это уже совсем другая история. Практика показывает, что для этого сейчас существует несколько векторов, внедрение вредоносного кода и различного рода "закладок" может быть выполнено не только на стадии предпроектной работы или ввода в эксплуатацию (этому свидительствуют возможности использования сторонних технологий, таких как VBS, WMI, и так далее, с помощью которых можно беспрепятсвенно взаимодействовать с системой, в том числе платформой)
0 |
Евгений Ваганович
06-10-2010 19:28:59
при этом ПАЗ не выдала ни одного уведомленияимеем цепь передачи данных PLK - OPS (самостоятельное приложение, например, kepware) - HMI (на 99% уверен, что в приведенном примере ситуация была такой). Корень проблемы - в недостаточной квалификации программистов АСУТП (конкретный вариант ошибки зависит от используемых компонентов: PLC, OPS и HMI). Знаю, что ряд проектов для очень крупных производств, делался (и продолжает делаться - ибо дешевле) простыми студентами и едва работает - делается все по принципу: "оно шевелится - и ладно", а более глубокое рассмотрение проблем им не важно/нужно/не могут проанализировать студенты. Поэтому данное событие (ПАЗ не выдала уведомлений) нельзя принимать во внимание (т.к. вся проблема в ЭТОМ случае целиком и полностью лежит на низкокачественном программном коде и конфигурации систем АСУ - "скупой платит дважды") и на практике же перед производственниками стоит проблема, чтобы такая АСУ (написанная студентами или аналогичными по уровню программистами) хоть как то кривовато, но работала. Это я вам говорю не как теоретик, а как практик, который с такими вещами сталкивался.
0 |
06-10-2010 22:59:50
OPC / PLC, если о терминологии для начала. Поэтому данное событие (ПАЗ не выдала уведомлений) нельзя принимать во внимание (т.к. вся проблема в ЭТОМ случае целиком и полностью лежит на низкокачественном программном коде и конфигурации систем АСУ - "скупой платит дважды") и на практике же перед производственниками стоит проблема, чтобы такая АСУ (написанная студентами или аналогичными по уровню программистами) хоть как то кривовато, но работала. Это я вам говорю не как теоретик, а как практик, который с такими вещами сталкивался. Речь идёт о том, что неавторизированное удаление технологического проекта привело к его останову без срабатывания системы ПАЗ, производитель признал ошибку класса "Ошибка в проектировании". Решение применяется в секторе химической промышленности, а именно - переработки амиака. Пример на рисунке - наглядно отображает схему построения проекта. (т.к. вся проблема в ЭТОМ случае целиком и полностью лежит на низкокачественном программном коде и конфигурации систем АСУ - "скупой платит дважды") Именно об этой проблемы мы и говорим, не о студентах - вопросы ввода в эксплуатацию заведомо уязвимых систем SCADA к нам не относится, мы занимаемся анализом защищённости и обеспечение безопасности технологических объектов.
0 |
Евгений Ваганович
07-10-2010 11:20:42
OPC / PLC, если о терминологии для началаесли не трудно - проверьте расстановку мною запятых (ну смешал я второпях русские и англ. буквы аббривиатур) производитель признал ошибку класса "Ошибка в проектировании"ну дык студенты ж дешелве кодят (ошибка же при проектировании самой АСУ, а не контроллера?). Возьмем по аналогии CMS какую нить - надо разделять ошибки в коде самой cms и ошибки, допущенные при ее конфигурации конечным юзером (программистом). Вдобавок - при проектировании ряда производств изначальна может быть заложена функция отключения оборудования при отказе СУ - как вариант, останов производства был не багом, а фичей - но это вряд ли Пример на рисунке - наглядно отображает схему построения проекта.рисунок отображает ход технологического процесса - не более. мы же имеем дело с АСУ мы занимаемся анализом защищённости и обеспечение безопасности технологических объектов.вот тут и весь корень обсуждения: для полноты доклада нужно было: 1. классифицировать виды ошибок по критериям: ошибки в базовом ПО системы (прошивки контроллеров, ПО HMI и прочее) и ошибки в конфигурации и проектировании самой системы (а-ля студенческий кодинг) 2. отдельно разобрать причины отказов верхнего уровня (HMI,OPC,БД) и нижнего (по некоторым классификациям - среднего) (контроллеры) В целом статья может дать неподготовленному человеку (то есть почти всем, кто не работает напрямую с АСУ), следующее положение дел: "шеф, все пропало, гипс снимают!", на самом деле же пока контроллеры практически неуязвимы при правильном проектировании (даже не при "правильном", а при "не похожем на маразм" - ибо значения перменных, их типы, а также обработку ошибок нужно изначально закладывать как базис)
0 |
07-10-2010 14:16:46
Мы говорим о том, что в составе АСУ есть различные элементы, например, системы диспетчеризации. В нашем докладе отражены разные элементы АСУ ТП, в том числе они, и другие тоже, надеюсь это ясно. На рисунке показана система диспетчеризации АСУ ТП, из которой был несанкционированно удалён технологический проект, при этом никаких уведомлений не появилось, по причине указанной выше. Я не знаю с чем, Вы конкретно имеет дело, мы имеем дело с тем, что описано выше. 1) Тип уязвимости указан и даже малоподготовленный человек понимает с чем это связано (классификация уязвимостей и соответствующих классов атак уже давно разработана, приведена в составе проектов CVE / CAPEC), наиболее подробная, но далеко не полная, классификация и соответствуя модель угроз приведена в документах ФСТЭК и Совета Безопасности РФ, которые составляют служебную тайну и секретно соответственно. 2) Причины отказов обширны, часть из них описаны в тех уязвимостях, которые мы афишировали, в скором времени выйдут такие же уведомления безопасности и под отечественные АСУ ТП и их элементы. Замечу, что это не статья, это аналитический отчёт, поэтому поняв это многие Ваши вопросы отпадут. Задачи показать какие-либо уязвимости не было - задача состоит в их обнаружении и устранении, конкретно - в ПО элементов АСУ ТП.
0 |
07-10-2010 14:21:04
ошибки в базовом ПО системы (прошивки контроллеров, ПО HMI и прочее) и ошибки в конфигурации и проектировании самой системы (а-ля студенческий кодинг) Вы сами различаете разницу в причинах появления программных уязвимостей, которые побудили создать ошибки в прошивках контроллеров, ПО HMI и ошибках, которые были допущены при её создании - либо вы различаете "студенческий кодинг" и "не студенческий кодинг, но с ошибками, которые приводят к уязвимостям"? Уверяю, что эти причины будут упираться в одно, - не только в этой сфере имеет место быть. Более того, перед техническими специалистами не должна ставиться задача поиска причинно-следственной связи от сущности и качеств разработчика до "релиза" уязвимости, наша задача - понять и выявить свойства уязвимости, разработать рекомендации для её устранения, направить рекомендацию разработчику. на самом деле же пока контроллеры практически неуязвимы при правильном проектировании (даже не при "правильном", а при "не похожем на маразм" - ибо значения перменных, их типы, а также обработку ошибок нужно изначально закладывать как базис) Вчитайтесь в свои слова и поймите, что Вы сами себе противоречите - "практически неуязвимы" достигается как или чем? Вашим советом или мнением? Конечно же, это не так. Вы смешиваете советы проектировщика, эксплуатанта, администратора и безопасника одновременно. Мы же говорим о другом, причины отказов перечислены. Я извиняюсь, мы можем с Вами очень долго здесь в комментариях общаться, гораздо проще разделить точки зрения, например, по электронной почте (komarov@itdefence.ru).
0 |
Евгений Ваганович
07-10-2010 19:36:00
наша задача - понять и выявить свойства уязвимостии отделить мух от котлет. не? "практически неуязвимы" достигается как или чем?элементарной культурой программирования Весьма рад был с Вами пообщаться ЗЫ - также приятно закончить общение на неменее приятной, уже второй за сегодня, капче - 55779
0 |
07-10-2010 19:52:34
и отделить мух от котлет. не? нет, - именно так, как я написал, при этом оповестив разработчика, чтобы впредь он такого не допускал, а совершенствовал качество своих продуктов. "практически неуязвимы" достигается как или чем? конечно, в этой связи так можно сказать для любой уязвимости, которая была обнаружена, не только в ПО элементов АСУ ТП, а известных платформах, сервисах и так далее. существует и второй момент, что сам разработчик воспитывает в себе мнение, наряду с пользователями его продуктов, что эти продукты "практически неуязвимы", именно в этом контексте я и задал вопрос.
0 |
Прохожий
07-10-2010 08:52:38
а что такое Sisco OSI? Может быть все таки Cisco? это в Таблица 5. Примеры эксплуатирующего кода в составе коммерчески распространяемых пакетов
0 |
07-10-2010 13:44:32
нет, к продуктам CISCO это не имеет никакого отношения, находится в составе SCADA SISCO MMS-EASE (http://www.kb.cert.org/vuls/id/145825)
0 |
Андрей
12-10-2010 11:38:58
Вроде статья новая, а про stuxnet ничего нет.
0 |
12-10-2010 18:05:37
«Rootkit.TmpHider» и «Scope.Rookit.TmpHider.2» (есть еще drop.stuxnet.a.5) - в пункте 3 это как раз о нём, http://www.securitylab.ru/analytics/extra/398183.php - соответствующая процедура, которая затрагивала конфигурацию WinCC для сбора информации, в Приложениях к обзору.
0 |
Александр Останин
17-10-2010 16:09:36
Да кстати Press release Началось похоже...
0 |
Страницы: 1  2