Size: a a a

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

2020 January 18

AS

Anton Shipulin in RUSCADASEC community: Кибербезопасность АСУ ТП
Anton Volkov
Все, проехали. Как-то даже неудобно такие очевидные и простые вопросы обсуждать. Будет что сказать конкретное в разрезе ИБ телекома и моей конкретики  - буду благодарен. Лечить на тему, как дела вести с подрядчиками, правильно писать ТЗ и проч. меня не надо, это не мой головняк.
Еще можно попробовать поискать основания для сегментации в проектной документации или гайдах вендоров тех систем которые объединяются. Мы же зачастую слышим "тут ничего нельзя менять, потому что так сказал вендор АСУ ТП. Только с разрешения вендора"
источник

AV

Anton Volkov in RUSCADASEC community: Кибербезопасность АСУ ТП
Anton Shipulin
Еще можно попробовать поискать основания для сегментации в проектной документации или гайдах вендоров тех систем которые объединяются. Мы же зачастую слышим "тут ничего нельзя менять, потому что так сказал вендор АСУ ТП. Только с разрешения вендора"
Точно, спасибо. Совет по существу.
источник

DD

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

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
А по результатам мониторинга определить критичные риски безопасности и планировать их поэтапно закрывать.
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Инвентаризация это базис. Не понимая что конкретно из себя представляет сеть невозможно её защищать.
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Кроме того, все эти базовые вещи практически никак не влияют на работоспособность систем.
источник

DD

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

AS

Anton Shipulin in RUSCADASEC community: Кибербезопасность АСУ ТП
Dmitry Darensky
Кроме того, все эти базовые вещи практически никак не влияют на работоспособность систем.
Дима, ты все верно говоришь но у коллеги конкретный вопрос не об этом
источник

AS

Anton Shipulin in RUSCADASEC community: Кибербезопасность АСУ ТП
Просит конкретное документированное(!) основание почему сваливать все в одну плоскую сеть в проекте это плохо и нельзя
источник

DD

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

DD

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

DD

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

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Автоматизаторов, безопасников или бизнеса.
источник

AS

Anton Shipulin in RUSCADASEC community: Кибербезопасность АСУ ТП
Dmitry Darensky
Ну пусть коллега к нам обратится с конкретной постановкой задачи, и мы ему предоставим всё что нужно. Тут важно понимать, для кого готовится обоснование.
Задача описана в его первом сообщении. Ооооочень подробно :)
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Я прочитал тред, для меня да и для других постановка не конкретная, раз развели весь этот холивар))
источник

DD

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

AL

Alexey Lukatsky in RUSCADASEC community: Кибербезопасность АСУ ТП
Anton Volkov
Коллеги, практический вопрос. Есть пром. объект. Относится к КИИ, категорирован по 3й категории. Имеет несколько изолированных (вот только не надо флейма про фейковость любого воздушного зазора сейчас начинать) АСУТП систем, состоящих из пары неупр. свичей, контроллеров и пары ПК, совмещающих роль серверов и АРМ-ов. Под изоляцией понимается полная изоляция. Т.е. не только отделенность от офисной сети, но и друг от друга. Там просто тупо нет СКС и вообще каких-либо кабельных линий, что бы быть с чем-то состыкованным. Отсутствие вайфая и свистков в ПК достигается мерами физическими. Запираемые шкафы, регламенты, ежедневные обходы, визуальный контроль. Но даже если тут есть огрехи, речь о другом.

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

Я профан в нормативке. Кроме здравого смысла, бест практик, что по букве закона РФ тут можно предъявить, что бы переломить ситуацию? По 239 приказу для категории 3 вроде сегментация не требуется. По 31му тоже. На какие бумажки сослаться?
А модель угроз есть? Почему нельзя туда просто добавить соответствующую угрозу (отказ в обслуживании) и для нее уже в обязательном порядке в соответствие с 239-м приказом реализовывать сегментацию. При этом моделирование угроз - это ваша ответственность, а не подрядчика
источник

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Задача какая, обязать подрядчика выполнить перепроекьирование или обязать сделать всё секьюрно?
источник

DD

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

DD

Dmitry Darensky in RUSCADASEC community: Кибербезопасность АСУ ТП
Функционального заказчика проект устраивает?
источник