Зоопарк неукротим или Хабр давно уже не тот

   Как-то раз сидел я в очередной командировке на очередном промышленном объекте, на котором выполнял работы по обеспечению защиты очередных АСУ ТП и КИИ от различного вида угроз, а параллельно участвовал в строительстве сетевой инфраструктуры заказчика. И вот после трудового дня решил почитать habr.com. А там замечательная статья под названием "Зоопарк на нефтебуровой: наводим порядок". У меня опыт работы в области безопасности промышленных сетей и систем небольшой - всего 6 лет (нефтепровод, протяженностью более 1000 км, добывающая промышленность, химпром, электроэнергетика). Поэтому тема интересная, решил ознакомиться, узнать что-то новое... После прочтения же мне захотелось написать очень большой комментарий, но, к сожалению, не хватает прав.

   С этого я и хотел бы начать новую рубрику, которую назову мягко - "Критика". Собственно, здесь будет много критики.

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

   Я же в свою очередь не хотел бы, чтобы в следующий раз очередной заказчик или подрядчик ссылался на такую статью в корпоративном блоге одного из крупнейших российских интеграторов и говорил: "Ну вот же ж! Они же строят так! Значит, нормально!"

   В этом разборе постараемся не вырывать слова из контекста, опираться только на то, что написал сам автор, т.е. будем делать прямые цитаты. Кроме того, мы не будем додумывать за автора, а понимать то, что он написал, буквально. Это тоже важно.

   Итак, поехали.

 

   НЕСКОЛЬКО СЛОВ О САМОМ ПОСТЕ

   Статья написана плохо. Я не знаю этого человека, поэтому не могу судить о нем никак, кроме как по данной статье. А по ней у меня создается впечатление, что автор не очень опытен. Скорее всего я ошибаюсь (а может и нет). Но если ошибаюсь, это всего лишь еще раз докажет, что хороший технический специалист != хороший рассказчик, причем, даже когда он рассказывает о своих проектах.

   В статье минимум технических деталей, потому что NDA. Сразу вопрос - раз NDA, зачем тогда вообще писать?

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

   Указанную заметку ни в коем случае нельзя воспринимать как руководство к действию или как пример для подражания. Только в определенных случаях, которые сведутся к 3 вариантам: а) нет денег, б) нет опыта и знаний, в) сложите а и б.

   КОММЕНТАРИИ, ПОЧЕМУ СТАТЬЯ НЕ ОЧЕНЬ

   Ну а теперь приступим непосредственно к разбору статьи. Далее курсивом будут выделены цитаты из поста с хабра (орфография и пунктуация сохранена), а далее мои комментарии обычным текстом.

   "Есть компания, которая строит месторождение или нефтебуровую платформу. У них есть отдельная локальная сеть под видеонаблюдение, отдельно под АСУ ТП, отдельно для доступа в Интернет, отдельно локальная сеть (по сути) для телефонии." - вводные данные, прямая цитата из поста. Как я понял, под отдельной локальной сетью понимается то, что строится полностью отдельная локальная сеть под каждые нужды. Сразу встает вопрос о том, как это все взаимодействует между собой? Явно же должны быть какие-то стыки и переходы одного в другое. Автор об этом умалчивает. А это очень важный момент, ниже будет пояснено, почему.

   "Это как если бы мы в такой корпоративной (производственной) сети вместо файрволлов использовали физическое разграничение сетей. В результате на многих предприятиях по десятку однородных решений. Владельцы переплачивают деньги за дублирующийся функционал." - Очень резкий переход. Первый абзац не связан со вторым. Фаерволы (Firewall, они же межсетевые экраны (МЭ)) используют не просто так, а для того, чтобы через них осуществлять безопасные стыки между указанными сетями различных назначений.   

   Назначение стыков и их необходимость - отдельный архитектурный вопрос. Сравнивать полностью изолированные физически сети с сетями с МЭ не совсем корректно. Ведь во втором случае у нас будет контролируемое соединение (при условии, что МЭ настроен и функционирует).

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

   Далее следует рисунок, который изображает несколько отдельных ЛВС различного назначения на двух площадках, которые объединены между собой ВОЛС, причем, между каждыми ЛВС на разных площадках  свои волокна, и каждая ЛВС имеет свое каналообразующее оборудование. 

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

   Выглядит довольно избыточно. Посмотрим, что же будет дальше.

  "Вот так выглядит «единая» локальная сеть. Гораздо эффективнее сделать одну сеть, где всё это объединяется. И вторую, чтобы был резерв. Мы сделали, и сейчас расскажу, что это дало." - Одну локальную сеть? И вторую локальную сеть, не связанную с первой, но дублирующую полностью её функционал для резервирования? Или вовсе один канал между площадками? Непонятно. Послушаем, что это дало.

   "Для ряда добывающих компаний мы делали тяжёлые комплексные проекты. Там десятки вендоров и сотни разных решений, всё это переплетено между собой. Есть оптика, радиорелейка, есть вайфай, радиодоступ по другим технологиям, есть индустриальные эзернеты, обычные телефонные станции, датчики IoT для АСУ ТП и многое другое.
Ни у кого нет стабильного решения по фен-шую: страшный зоопарк из легаси даёт о себе знать. Ещё в этой сфере часто случаются слияния-поглощения и получается, что два разных зоопарка объединяются. Получается зоопарк в квадрате." - стоп, стоп, стоп. Я опять запутался. Мы в самом начале обсуждали разные ЛВС под разные нужды. А теперь ВНЕЗАПНО перешли к тому, что у заказчика технологический и вендорный зоопарк. Мы какую задачу-то решаем? Мы ж вроде боролись с дублированием функционала, а не с зоопарком производителей систем и оборудования? Да и чего бороться с зоопарком производителей. Тут вариант один и явный - строим системы на 2х-3х вендорах под наши нужды. И даже голову не нужно греть. Это первое.

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

   В общем, целых два абзаца мимо первоначального посыла статьи.

   "Наша задача — убедить заказчика, что объединение сетей безопасно. Это главный стопор прогресса, например, в нефтяной сфере: здесь, как нигде, используется принцип «работает — не трогай»." - как вы могли заметить, пост полон ВНЕЗАПНОСТЕЙ. Сначала мы разговаривали о ЛВС, потом о производителях, а теперь у нас новая задача - убедить заказчика в безопасности  - Нет, не предлагаемого решения. А в безопасности объединения всех сетей в одну сетку. Где тут безопасность вообще - непонятно. Безопасность чего? Конкретной системы или чего? Сферическая безопасность в вакууме? А как же вообще основные характеристики промышленных сетей, который включают в себя надежность, доступность, управляемость и т.д.? 

   "Во-первых, АСУ ТП-часть всегда использует другие коммутаторы, нежели остальные части сети. Это серьёзное удорожание, но это исторически правильно. Предполагается, что АСУ ТП будет работать в любых условиях, поскольку как минимум формально она отвязана от Интернета." - Использование отдельного оборудования АСУ ТП от остального оборудования - прекрасно. Оно не столько историческое, сколько архитектурно правильное. И точно так же правильно, что оно должно быть отвязано от интернета. Причем не формально, а реально. И лучше всего выделить его в отдельный сегмент (логический и физический) и запустить в ДМЗ через МЭ. И в Интернет АСУ ТП вообще выпускать не надо НИКОГДА.

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

   Но даже не это главное. Как можно согласиться с тезисом "физическая изоляция сетей не гарантирует изоляцию от зловредов", ведь если ЛВС полностью изолированы, значит как минимум появление зловреда в одной ЛВС никак не повлияет на сторонние ЛВС.

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

   "Видеонаблюдение: считается, что нет необходимости защищать его так, как АСУ-сегмент." - Видимо, считается конкретно этим заказчиком. Потому что в общем считается, что защищать нужно все. И только конкретные заказчики могут либо ничего не защищать вообще, либо быть параноиками.

   "Да, либо сеть строится отдельно и на аналоге (очень дорого), либо считается, что она условно защищена. В моей практике можно отвернуть камеру и получить доступ к сети. Либо подменить картинку, и никто в ближайшие полгода до конца зимы не узнает. Проверяется доступность камер и наличие картинки. Многие чувствуют себя так в безопасности: картинка может не меняться 100 лет. Тундра и тундра. Надо объезжать и смотреть, что и где." - Прекрасно. Действительно, не всегда заказчиками уделяется внимание защите мест подключения конечных устройств, тем более камер. Но как указанное выше поможет убедить заказчика, что объединение сетей лучше, чем полностью изолированные друг от друга ЛВС, лично мне абсолютно непонятно. Кроме ценового фактора никакой другой фактор здесь не применим. И уж с точки зрения безопасности все как было плохо, так и осталось.

   "В итоге мы ответили на все вопросы безопасников. Давайте перейдём к деталям." - Как видно выше, ни на один вопрос от безопасников никто не ответил. Аргументы типа "Да все равно у вас и сейчас не очень безопасно, так что в нашем случае будет так же небезопасно, но зато дешево" - так себе аргументы.

   Раздел "Пример" состоит из двух схем, на которых мы видим объединенные ВОЛС, появившийся МЭ канале, подключенные к нему ЛВС. Никаких пояснений, кроме того, что мы очень заботимся о каналах между площадками. Что? Как? Зачем? Ответов не будет. И так ясно, что лучше иметь релейку и волокно, чем только релейку или только волокно. Бесполезный раздел.

   Переходим к разделу "Результат". Тут уже появляются какие-то масштабы предприятия, к которому автор применяет "свои наработки".

   "В нашем примере есть нефтепровод — примерно сотня километров.
  Мы объединили сети в единый комплекс, как на схеме выше. Отказоустойчивость достигается через радиорелейные мосты, есть резервирование телефонии через транкинговую сеть (интегрируется через рации для вызова абонентов телефонной сети)." - нефтепровод скорее всего от месторождений к узлам подготовки нефти, где она дегазируется и обезвоживается. Здесь начинает проясняться замысел автора. Буровые с кустами, расположенные в тундрах, тайгах и болотах. Вон чего. Тогда скорее всего телефония - это пара IP\Аналоговых телефонов, пара коммутаторов для подключения всего и вся и т.д. Возможно стоит пара ПЛК, к которым подключаются датчики. И обо всем этом автор умолчал, а в тексте встречались слова "масштабные" и "комплексные". И это тоже важно! Почему? Да потому что в первом же комментарии к этому посту человек разъяснил для себя, что СОТИ АССО на ЭнергоАтоме можно было сделать аналогично, с объединением сетей. НЕТ, НЕЛЬЗЯ БЫЛО. Ниже пример того, что из себя представляет буровая с кустом (панорама):

   Обратите внимание, за что мы боремся. Тундра, нет источников питания, кроме дизеля, от которого запитывается все. На заднем фоне видна будка, где сосредоточена вся инфраструктура. Таким образом объединить все сети можно именно на месторождении, где а) экстремальные условия, б) проблемы с размещением, в) проблемы с обслуживанием, г) множество других проблем.

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

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

   

   "Как разграничивается трафик? Сейчас я нарезал VLAN'ы. Условно АСУ ТП имеет высочайший приоритет, затем видео и телефония, остальной трафик — дальше." - сейчас речь, видимо, о QoS. А трафик разграничиваем VLAN'ами. Если кто-то вдруг не понял.

   "Почему набор VLAN безопасен в сравнении со старым добрым физическим разграничением?" - действительно, почему. Особенно если учесть, например, атаку типа Vlan Hopping, а в известном дистрибутиве для пентестинга есть соответствующие инструменты "из коробки".

    "Когда ты делишь физически, у тебя под каждую задачу своя железка. Это абсолютно безопасно. Если злоумышленники попали на одну железку, они не попадут на соседнюю." - и с этим сложно спорить.

   "Нужно добраться до сегмента управления. Есть общая точка взлома — это менеджмент-сеть." - в начальных данных этого не было! Никто не говорил, что у заказчика есть внеполосное управление (Out-Of-Band Management, OOB). На практике же на подобных малых предприятиях его, естественно, нет вообще. Управление осуществляется напрямую в общем трафике. А раз сети разделены, то и нет общего сегмента управления. Опять нет нормально оформленных начальных данных.

   "Соответственно, если есть единая точка отказа, то какая разница, на одной железке виланы нарезаны или всё крутится на разных." - а вот тут автор путает понятие "точка проникновения" и "единая точка отказа".

   Точка проникновения\взлома - это место, где произошел инцидент. Собственно, вспоминаем базовую терминологию.

   Единая точка отказа - это место, где все системы лягут одновременно. Именно такую точку автор и создает, объединяя разрозненные ЛВС в сеть на одном оборудовании. По крайней мере на словах из поста.

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

   "Пользователи изолированы, они не видят юзеров из соседних виланов. Вероятностная характеристика каких-то проблем в виртуальных сетях ненамного выше такой же оценки в физических разделённых сетях. Коммутаторы можно сделать изолированными, кластеры коммутаторов, оптические линки будут дублированы. Таким образом, вероятность отказа минимизируется." - без математических выкладок и анализа этот абзац вообще ничего не значит. Что значит вероятностная характеристика ненамного выше? Выше уже писал: вероятность того, что ляжет вся буровая гораздо ниже при разделении по отдельным железкам.

  Что значит "коммутаторы можно сделать изолированными" - от чего изолированными? Я не очень понимаю этот абзац, объясните кто-нибудь.

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

    "Вторая причина в том, что, если есть три разные сети, их крайне редко дублируют все три. Мы предложили вариант совместить отказоустойчивые коммутаторы, отказоустойчивые ЛВС — ключевые роли тут задублированы, но, соответственно, все сети мы поделили виртуально." - опять же различны варианты. Оценку степени важности системы и степени критичности простоя никто не отменял, далее на основании этой оценки можно понять, какие системы нужно дублировать, а какие нет. В случае же объединения в плохом варианте у нас падают все сети. Сразу. Без вариантов. Понятно, что не должны. Но и такое случается.

   "Сделали расчёт и показали, что на самом деле такое решение где-то на треть дешевле. Можно минимизировать количество прокладываемой оптики, минимизировать время восстановления. Потому что, если у тебя порвали оптическое волокно, например 8-волоконное, у тебя время восстановления условно полчаса, если это 32-волоконное — сильно больше. Тоже сокращает издержки на обслуживание." - про издержки уже писал выше.

   Раздел "Каналы" можно опустить, потому что там нет ничего интересного. Перейдем сразу к итогам. Итоги у нас не утешительны:

   "В итоге мы можем собрать весь зоопарк в одно решение за счёт виртуального разграничения сетей. Это в два раза лучше по кабелю и в три раза лучше по зоопарку железа на узлах в количестве единиц. ИБ снижается незначительно, отказоустойчивость растёт за счёт полного дублирования ключевых узлов. Проще, быстрее и дешевле обслуживание.
  Используются дорогие коммутаторы для АСУ ТП, через них трафик АСУ ТП идёт с высочайшим приоритетом. Потом отправляется остальное.
  За объективно небольшой компромисс в безопасности можно получить существенное упрощение поддержки, унификацию решения и экономию по питанию и капитальным затратам." - в итоге мы снизили надежность сети, обрисовали заказчику выгоду в попугаях, сообщили, что ИБ снижается незначительно, хотя нигде не подтвердили это. Зачем использовать тут дорогие коммутаторы, когда лучше бы использовать надежные - тоже не ясно. Оценку объективности компромиссов никто не показал, в чем унификация - тоже непонятно. Выбрали в итоге одного вендора что ли? Так и раньше было ясно... Единственный существенный плюс - это сокращение затрат по питанию. Тут без шуток правы.

   А ТЕПЕРЬ САМОЕ ГЛАВНОЕ

   А самое главное то, что я понял, что хотел сказать автор. И он, как это ни странно, во многом прав. И VLAN используются, и сеть объединяются, и другими ухищрениями тоже пользуются на практике, в том числе и для удешевления стоимости проекта.

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