Я уже не раз писал, что одной из пока нерешенных проблем в ИБ АСУ ТП, является обеспечение целостности и конфиденциальности (если предположить, что их нужно все-таки обеспечивать). И вот в докладе «Инсайд РУС» и предлагалось решение этой задачи. По сути была разработана СКЗИ на базе отечественных ГОСТов, которая позволяла реализовывать отечественные криптоалгоритмы в системах промышленной автоматизации.
Ну, думаю, свершилось. Наконец-то. Смогли эффективно реализовать ГОСТы в железе, да еще и с учетом специфики протоколов АСУ ТП, где одно из ключевых требование — низкие задержки (особенно в электроэнергетике). Но потом посмотрел слайд с оценкой результатов работы представленного решения и понял, что до радости пока далеко.
В АСУ ТП важна не скорость передачи данных, а приспособленность к небольшим размерам пакетов (в несколько бит) и отсутствие задержек. А про то, при каких длинах пакетов измерялись вышеприведенные значения, не сказано.
Допустим, у нас есть подстанция, которая передает данные в размере нескольких бит, по каналу 56 Кбит/сек с требованием по задержкам (по стандартам электроэнергетики) 10 в минус 6-ой. И вот как при таких исходных данных, повсеместных в России, будет работать предлагаемое решение? Никак. Ибо такие условия наши ГОСТы по криптографии вообще не в состоянии учитывать 🙁 К счастью, и требований по криптографической защите в АСУ ТП пока нет.
Проблема ещё и в инкапсуляции пакетов данных в шифрованные дейтаграммы.
Например, ВиПНет добавляет заголовок ~80байт + хвостик. В результате мелкий пакет может потолстеть в 2 раза. В случае с АСУ ТП — в 10 раз 🙂
Ну, шифрование как броня — увеличивает габариты. При достаточной пропускной способности канала — допустимо.
Обратите внимание на последний абзац — там все четко написано по поводу пропускной способности. Шифровать надо не гигабитный канал, а 56 Кбит/сек и не на максимальных длинах TCP-пакета, а всего несколько бит
Отправил докладчику ссылку на пост. Возможно, захочет как-то прокомментировать.
Угу. Спсибо
Не в качестве рекламы, но мне больше по душе концепция одной российской компании — использовать внешнее устройство для имитовставки с регулируемой частотой (хоть в каждый пакет, хоть один пакет имитовставки в день).
Именно шифровать в ситуации "есть подстанция/КП ТМ/whatever с каналом в 56к" попросту нечего.
А вот подмена сигнала или навязывание ложного сигнала может быть вполне реальной угрозой (особенно второе, особенно, когда канал беспроводной)
Имитовставка — м.б. стандартнрй процедуррй для шифрованного сообщения. А только имитовставка не решает вопрос конфиденциальности сообщения.
А только имитовставка не решает вопрос конфиденциальности сообщения.
А потом автоматизаторы нам опять обоснованно говорят, что ИБшники ничего не понимают и лезут со своей защитой 🙁
Ну какая конфиденциальность у сигнала?
Если мне надо удаленно перекрыть вентиль, то мне надо, чтобы:
1. Вентиль именно перекрылся, а не наоборот
2. Это мог сделать только я, а не кто попало.
То, что с фактом перекрытия вентиля может ознакомиться кто угодно — уж как-нибудь пережить можно.
мы о разных объектах защиты говорим… "Именно шифровать в ситуации "есть подстанция/КП ТМ/whatever с каналом в 56к" попросту нечего" — вам нужно защититься только от ложного навязывания, система "свой-чужой" для управляющих сигналов, и логично предлагаете использование имитовставки; а я говорил о необходимости использования шифрования инфо сообщений (!), а не сигналов, в конкретно оговоренных условиях текста.
Конфиденциальность может быть обеспечена не только 256-тибитными ключами
А какого текста? Заметки или презентации?
Уважаемый Алексей,
Для начала, хотелось бы поблагодарить Вас за проявленный интерес к нашему продукту.
Создавая универсальный модуль безопасности "ИНСАЙД РУС. ГОСТ" мы ставили своей основной задачей создать устройство, которое сможет надежно противостоять угрозам информационной безопасности в области промышленной автоматики. В частности, действиям злоумышленников, направленных на подмену или навязывания команд, "перехват" авторства. Данные задачи могут решаться различными криптографическими способами, реализацию которых мы предусмотрели в нашем устройстве: шифрованием, имитовставкой, цифровой подписью и т.д.
Разумеется, мы не обеспечиваем уровень задержки "10 в минус 6-й", точно также, как подобный уровень задержки не обеспечит и внешнее устройство. Как мне кажется, только временные потери на коммутацию будут выше.
Однако, например, для защиты управляющих команд, поступающих на исполнительные устройства, или же для обеспечения достоверности информации, поступающих от датчиков системы smart grid нашей производительности вполне достаточно. Мы делаем такой вывод опираясь на мировой опыт, в частности на разработки, связанные с протоколом OSGP (Open Smart Grid Protocol) и мнение экспертов, принимавших участие в разработке.
При этом мы готовы к развитию нашего продукта, консультационной и технической поддержке специалистов, работающих с ним. Если у наших Коллег будут пожелания, предложения и вопросы по реализации и использования вышеперечисленных функций — с радостью обсудим.
С разработками в области Smart Grid я тоже немного знаком. Поэтому я и написал эту заметку. Я пока не вижу применения ГОСТа в АСУ ТП. Вообще. Он избыточен и только вносит дополнительные задержки без толку. Та стойкость, которую он обеспечивает, избыточна
Мы понимаем, что стойкость ГОСТа может быть избыточна для АСУ ТП, но других криптоалгоритмов, которые являются легитимными, в РФ нет.
Легитимными в том смысле, что авторитетная организация, а именно, наш регулятор, может подтвердить качество разработанного решения.
Поэтому мы создали и предлагаем нашему рынку именно такое решение."
Ну регулятор же пока не подтвердил ничего — сертификата на решение вроде нет. Но дело даже не в этом, а в том, что вместо того, чтобы менять ситуацию, вы под нее подстраиваетесь. И непонятно зачем, если большинство заказчиков не будет использовать такое решение, которое только мешает из-за своих характеристик, неоптимизированных для АСУ ТП 🙁
Алексей,
К сожалению, "менять ситуацию" в данном случае мы не в силах… А оптимизация заключается в разумном применении нашего решения. У продвигаемого нами Inside Secure уже несколько лет существуют подобные решения без ГОСТ (и они используются различными коммерческими организациями в России). Мы рассказывали об этом на предыдущих конференциях РусКрипто. В то же время, многие наши заказчики требовали от нас только ГОСТированных решений. Такое решение мы реализовали и представили рынку в начале 2015 г. В любом случае, каждый заказчик может выбрать то решение, которое он сочтет оптимальным для свои задач.