Size: a a a

RUSCADASEC community: Кибербезопасность АСУ ТП

2018 December 26

v

vadim.s. in RUSCADASEC community: Кибербезопасность АСУ ТП
У Даренского понравилась презентация. Правильные вещи и адекватное представление ситуации.. Жаль с позитивом никак сконектиться не могу...
источник

v

vadim.s. in RUSCADASEC community: Кибербезопасность АСУ ТП
Коллеги из ЛК хоть и не совсем про асутп, но очень интересно рассказали и показали. Большая часть атак на асутп ведь начинается с корпоративки... Хороший формат.
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
vadim.s.
У Даренского понравилась презентация. Правильные вещи и адекватное представление ситуации.. Жаль с позитивом никак сконектиться не могу...
Коннектиться мы всегда готовы) укажите сорсы и дисти, всё полетит)
источник

AL

Alexey Lukatsky in RUSCADASEC community: Кибербезопасность АСУ ТП
Egor
что мешает атаковать со стороны промышленных протоколов? т.н. "атака снизу вверх"
По статистике атака ICS начинается с атаки на корпоративную сеть традиционными методами. Так начинался HAVEX, BlackEnergy и др.
источник

AK

Alexander Kremlev in RUSCADASEC community: Кибербезопасность АСУ ТП
Я бы перефразировал так, атака ics возможна в случае сопряжения технологической с корп сетью.
источник

ED

E D in RUSCADASEC community: Кибербезопасность АСУ ТП
она в 90% случаев сопряжена. а если не сопряжена, то есть вектора и на этот случай
источник

AS

Anton Shipulin in RUSCADASEC community: Кибербезопасность АСУ ТП
Alexander Kremlev
Я бы перефразировал так, атака ics возможна в случае сопряжения технологической с корп сетью.
Лучше всего список векторов атак указан в MITRE ATT&CK в тактике "Initial Access", что применимо и в АСУ ТП. Где видно что есть не только сопряжение с корпоративной сетью

Initial Access:
1. Drive-by Compromise
2. Exploit Public-Facing Application
3. Hardware Additions
4. Replication Through Removable Media
5. Spearphishing Attachment
6. Spearphishing Link
7. Spearphishing via Service
8. Supply Chain Compromise
9. Trusted Relationship
10 Valid Accounts

https://attack.mitre.org/
источник

T

TopKa in RUSCADASEC community: Кибербезопасность АСУ ТП
Viktor Gordeev
тут надо ещё понимать экономическую составляющую (сколько хакеры затратят своих средств на атаку). Например в металлургии дешевле закидать в вагон дорогой металл и присыпать металлоломом и вывезти с территории для продажи.
Нат мет комбинатах есть более дорогие материалы чем прокат (листы, рулоны).
источник

ED

E D in RUSCADASEC community: Кибербезопасность АСУ ТП
имхо, оптимально исходить из того, что вероятность нахождения нарушителя  внутри сети высока и строить  механизмы  максимально быстро позволяющие вычислить его...
источник

T

TopKa in RUSCADASEC community: Кибербезопасность АСУ ТП
Dmitry Darensky
Контроль целостности и версионности конфигов например он должен быть увязан с многими другими вещами. Например, если тот же кикс поднимет флаг о том что хеш на плк не бьётся, то необходимо проверит, кто и зачем это сделал.
Для того чтобы контролировать конфиги плк (проектов) надо еще понимать что конкретно надо контролировать. Есть постоянно изменяющаяся часть - данные. А есть редко изменяющаяся - сам код программы. Если изменился хеш программы, то это инцидент при условии что не соблюдена процедура изменения кода программы. Но блок данных так же может меняться по разному, это либо изменения в следствие работы контроллера - переменные, но есть и данные которые просто так не должны меняться, яркий пример, уставки, шкалы и т.д. Вопрос - сейчас системы контроля целостности плк  умеют контролировать изменения конктретных объектов плк?
источник

AK

Alexander Kremlev in RUSCADASEC community: Кибербезопасность АСУ ТП
E D
она в 90% случаев сопряжена. а если не сопряжена, то есть вектора и на этот случай
Сопрягать по разному можно, можно через средний уровень, дата диоды, однонаправленные соединения через ДМЗ и прочее.
источник

AK

Alexander Kremlev in RUSCADASEC community: Кибербезопасность АСУ ТП
TopKa
Для того чтобы контролировать конфиги плк (проектов) надо еще понимать что конкретно надо контролировать. Есть постоянно изменяющаяся часть - данные. А есть редко изменяющаяся - сам код программы. Если изменился хеш программы, то это инцидент при условии что не соблюдена процедура изменения кода программы. Но блок данных так же может меняться по разному, это либо изменения в следствие работы контроллера - переменные, но есть и данные которые просто так не должны меняться, яркий пример, уставки, шкалы и т.д. Вопрос - сейчас системы контроля целостности плк  умеют контролировать изменения конктретных объектов плк?
Если несанкционированно изменятся переменные  на узле учета то это инцидент не менее значимый чем изменение кода.
источник

ED

E D in RUSCADASEC community: Кибербезопасность АСУ ТП
Alexander Kremlev
Сопрягать по разному можно, можно через средний уровень, дата диоды, однонаправленные соединения через ДМЗ и прочее.
Главное что вектор есть, а механизмы защиты не панацея... меня ДМЗ еще ни разу не остановила при  тестировании ТС )
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
TopKa
Для того чтобы контролировать конфиги плк (проектов) надо еще понимать что конкретно надо контролировать. Есть постоянно изменяющаяся часть - данные. А есть редко изменяющаяся - сам код программы. Если изменился хеш программы, то это инцидент при условии что не соблюдена процедура изменения кода программы. Но блок данных так же может меняться по разному, это либо изменения в следствие работы контроллера - переменные, но есть и данные которые просто так не должны меняться, яркий пример, уставки, шкалы и т.д. Вопрос - сейчас системы контроля целостности плк  умеют контролировать изменения конктретных объектов плк?
В ISIM есть возможность контролировать отдельные уставки или теги. В смысле написать детекты на его отклонения, указать прикладной смысл такого инцидента, возможные импакты, меры по реагированию.
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Так же есть возможность отследить действия по отношению к конфигам и фирмвари.
источник

T

TopKa in RUSCADASEC community: Кибербезопасность АСУ ТП
Alexander Kremlev
Если несанкционированно изменятся переменные  на узле учета то это инцидент не менее значимый чем изменение кода.
И да и нет. Поясню. есть код контроллера, в области данных контроллер сохраняет промежуточные значения и в идеале если эти данные снаружи менять, то это ни как не влияет на работу контроллера из-за высокого быстродействия контроллера. Но это в идеале и если код правильно спроектирован. Но есть данные, константы в виде уставок блокировок, которые меняются редко и они напрямую влияют, например, на безопасность.
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Продукт нашего партнёра может и хеши отследить, и визуализировать изменения в блоках и связях в конфига по отношению к версии конфига который должен исполняться
источник

T

TopKa in RUSCADASEC community: Кибербезопасность АСУ ТП
Dmitry Darensky
Продукт нашего партнёра может и хеши отследить, и визуализировать изменения в блоках и связях в конфига по отношению к версии конфига который должен исполняться
VersionDog?
источник

AK

Alexander Kremlev in RUSCADASEC community: Кибербезопасность АСУ ТП
TopKa
И да и нет. Поясню. есть код контроллера, в области данных контроллер сохраняет промежуточные значения и в идеале если эти данные снаружи менять, то это ни как не влияет на работу контроллера из-за высокого быстродействия контроллера. Но это в идеале и если код правильно спроектирован. Но есть данные, константы в виде уставок блокировок, которые меняются редко и они напрямую влияют, например, на безопасность.
На флобосах например, такие константы называются nmi для них crc отдельно считается.
источник

T

TopKa in RUSCADASEC community: Кибербезопасность АСУ ТП
Dmitry Darensky
Продукт нашего партнёра может и хеши отследить, и визуализировать изменения в блоках и связях в конфига по отношению к версии конфига который должен исполняться
Буду очень рад если это будет реализовано в рамках одного продукта
источник