Category: технологии

Category was added automatically. Read all entries about "технологии".

World

Дежа вю. Впечатления от SOC-Forum

«… воображение расцветает лишь тогда, когда оно свободно от оков, в неволе же оно чахнет и хиреет. Скованные фантазии прокисают и начинают бурно бродить, поскольку лишены своего главного естественного ограничителя, имя которому – Разум»
(с) Терри Пратчет

Активно участвовать в мероприятиях по информационной безопасности я начал только этой осенью. Хотя опыт участия в различных конференциях, выставках, семинарах и других публичных мероприятиях у меня достаточно богатый, так что есть с чем сравнивать.
Долго думал стоит ли мне писать о самом форуме, насколько мнение «начинающего» может быть интересно «старожилам», не будут ли мои оценки чересчур субъективны и непрофессиональны. Последним толчком к написанию данного обзора послужил обзор на эту тему Дмитрия Дудко (Dudko Dmitry http://ddudko.ru/soc_forum_overview/), где он, задав ряд вопросов выступающим, не оставил шанса ответить, так как комментировать разрешил, только «друзьям». Итак, приступим.
Начну с того, что сам форум мне понравился. Да были изъяны в организационной части, может быть место проведения было выбрано не самое удачное, но по содержательной части такие мероприятия крайне важны для любой тематики, которая предполагает серьезное развитие в ближайшем будущем. Это, в том числе, подтверждает количество участников, их состав и спектр обсуждавшихся вопросов.
С первых минут, стало понятно, что сам термин Secure Operational Center, не сегодняшний день, маркетинговое понятие, однозначного определения которого, сегодня не существует. В этом смысле уникальность форума в том, что формирование новых направлений происходит только там, где нет устоявшихся границ, нет четких определений, где необходимо уметь анализировать, придумывать и предлагать. Мне приходилось участвовать в подобных этапах по развивающимся тематикам и в других отраслях, например, АСКУЭ (автоматизированные системы контроля (коммерческого) учета электроэнергии), САЦ (ситуационно-аналитические центры), Цифровые подстанции и т.д. Сценарии очень похожи, меняются действующие лица. Отдельное спасибо, ведущему Олегу Седову (Oleg Sedov), пленарное заседание он провел профессионально, не давая, президиуму уйти в работу «по секциям», а с другой стороны, давая озвучить весь диапазон мнений по теме. Жаль, никто не составил перечень повисших в воздухе вопросов, неважно отвечали ли на них или нет, так как любой ответ в данной ситуации – это только частное мнение, а их совокупность – это техническое задание, которое позволит в будущем начать формировать документы, позволяющие более четко формализовать функционал SOC и область его применения в России. Ну и конечно нельзя не отметить уровень конферанса, тон которому был задан фразой «Две забавы в России: революции и сертификации», подкреплен (в процессе особенно жаркого обмена мнениями) «два регулятора и Сычев», ну и на посошок «Пресса и деньги возьмет и правду напишет». Благодаря ведущему, несмотря на переполненный зал и большой разброс мнений по одним и тем же вопросам в президиуме и в зале, пленарная сессия прошла конструктивно и спокойно.
Теперь по сутевой части пленарной сессии. Я не готов восстановить сейчас полный перечень обсуждавшихся вопросов, но часть из них позволяет задуматься о том, что же реально ждут от внедрения SOC и каким его видят участники с различных сторон «баррикад». Начнем с самого простого, коммерческие SOC, которые активно создают, практически все крупные интеграторы, а Positive Technologies даже уже решил пропиарится отказом от создания самого SOC, но тут же предложил сервисы остальным игрокам. Опять таки, ситуация один в один, как в других отраслях, пока понятие не устоялось, нет четкой терминологии и рынка услуг, почему бы не быть первым и не снять с рынка сливки.  Отсюда и звучавшее воззвание к регуляторам, обяжите Заказчиков! Желание понятно и как я уже говорил неоригинально. Опыт показывает, что регуляция (государственная, ведомственная или групповая) появляется только тогда, когда предлагаемый функционал начинает выполнять роль поддержки, какого-то другого бизнес-процесса более высокого уровня. Например, АСКУЭ, регуляция появилась в момент, когда необходимо было запустить Оптовый рынок электроэнергии, расчеты на котором требовалось легитимизировать. Тема САЦ стала актуальной, после аварии на Саяно-Шушенской ГЭС, когда выяснилось, что у первых руководителей энергокомпаний отсутствуют инструменты контроля процессов на местах. Что может послужить триггером в данном сегменте, сложно сказать, могу высказать два вероятных сценария развития событий.
Первый, обозначил позже на одной из сессий представитель 8-го центра ФСБ, представляя систему СОПКА. В предыдущих обзорах обсуждался уровень готовности системы, ее работоспособность и т.д., но это, на данный момент, не важно. Важен сам сценарий, возникает доверенный SOC, один на всю страну, куда автоматически директивно включаются все госпредприятия, в этом случае коммерческие SOC с этого рынка уходят и им остается пойти по пути Positive Technologies, предлагая сервисы Заказчикам, до момента пока они не освоят бюджеты по формированию собственных аналогов, купленных у тех же интеграторов, которые выстроятся в очередь на получение сертификатов о совместимости их решений с СОПКА. Да при этом остается еще банковский сектор и коммерческий рынок, но он в последние годы в России сужается и такого количества коммерческих SOC будет просто не нужно. Ответ на вопрос Алексея Лукацкого (Alexey Lukatsky) по ответственности коммерческих SOC, в данном сценарии будет звучать так, если SOC (его сервисы) сертифицированы для работы с СОПКА, то если не было нарушений со стороны подрядчика, то никакой, есть сертификат, все должно работать, в этом весь смысл таких конструкций, прошу прощения за банальность.
Второй сценарий, связан с рынком страхования. В мире страховые компании активно страхуют риски по информационной безопасности. Для страховых компаний – это достаточно емкий сегмент бизнеса, учитывая общую ситуацию в мире. Для Заказчиков – это возможность хеджировать риски в области, в которой «эффективный» менеджмент не в состоянии сформировать показатели ROI, основанные не на страшилках, а на реальных расчетах. В данном сценарии страховые компании уже определяют требования к функционалу SOC (неважно внешних или внутренних), что напрямую связано со страховыми тарифами. В этом случае ответом на вопрос Лукацкого, будет являться аккредитация SOC у страховой компании и потеря такой аккредитации (а соответственно денег), при появлении непредусмотренных инцидентов.
     Для Заказчиков, все гораздо сложнее, он, как и в любой отрасли, платит за все. В первом сценарии, если все будет развиваться директивно, скорее всего все пойдут по пути создания собственной иерархии SOC, функциональность которых будет определяться степенью проработанности требований и готовности собственной инфраструктуры их выполнить. Во втором сценарии, потребуется два-три года на формирование устойчивого рынка услуг и как следствие формирования уровня цен. Безусловно, возможных сценариев десятки и я попытался привести только крайние «регуляционный» и «коммерческий».
Я выступал с докладом на сессии «Опыт построения SOC», поэтому скажу пару слов именно об этой сессии. Начнем с того, что попал я туда случайно. Числа второго ноября, наткнулся на статью в блоге Лукацкого, с упоминанием SOC-Forum, пока согласовал с руководством участие компании в форуме ушло еще несколько дней, короче к моменту подачи заявки «на флажке», вторая сессия, которую модерировал, как раз Алексей «Технические средства построения SOC», где я предполагал выступать, похоже была переполнена. И меня уверенно поставили в состав, выступающих второй сессии. На мой звонок организаторам с подробными объяснениями, почему это не совсем корректно, реакция была как на радио, то есть никакой. Хотя теперь, оценивая произошедшее и уровень моего выступления, в части технических деталей, возможно судьба мне помогла. На сессии Алексея, наверно моя более концептуальная, чем техническая, презентация, да еще на нишевую тематику SOC в критической инфраструктуре, смотрелась бы бледно, с другой стороны, хотя моя презентация содержала представление трех нишевых продуктов, но их описание было дано, исходя из опыта их использования (правда не в России) в составе систем, которые вполне подходят под описание SOC.
Итак, сессия «Опыт построения SOC». Я не буду подробно останавливаться на каждом докладе, просто сделаю несколько ремарок. Первым выступал представитель РЖД, который подробно рассказал об эксплуатируемом внутреннем «SOC», созданном на базе своих разработок. Хотя Дмитрий Дудко в своем обзоре негативно отнесся к содержанию доклада, зная внутреннюю инфраструктуру данной компании, могу сказать, что при создании системы объем работ проделан громадный объем работ, как технический, так и организационный. Высказанное Дмитрием предположение из непроверенных источников, что ЦБИ не работает думаю отчасти верно. Как SOC, в его понимании термина (четкого определения то нет), наверно не работает, но те задачи, под которые он создавался внутри организации решает, иначе эти люди бы не продолжали там работать. С другой стороны, создан прецедент, его теперь можно совершенствовать (здесь даже полная замена будет названа модернизацией), первый шаг, самый трудный уже сделан. И то, что в следующем докладе Информзащита рассказывала о создаваемых региональных элементах SOC в той же РЖД, у меня абсолютно не вызывает удивления. Теперь по вопросам к моему докладу:     Как иностранный GRC применять в РФ? Правильно ли что вы предлагаете «консультант» с практиками по ИБ? Не вижу проблем (кроме одной из «забав», из цитаты Седова) применять продукт GRC израильского производства в России, тем более, что его производители имеют экспертизу в области разработки ИБ стандартов в Европе и США. Подготовка корреляции международных правил с российскими и внутрикорпоративными проводится по отлаженной технологии. Опыт проектов в финансовой и технологической областях позволяет гарантировать Заказчикам качественный результат. Второй вопрос: Как происходит обновление фидов в сегменте АСУ ТП без интернета? Никак не происходит. В сегменте АСУТП решаются немного другие задачи. Каждая АСУТП детально документирована, каждый элемент имеет описанный функционал и режимы работы. Система, о которой шла речь, позволяет описать набор правил, описывающих поведение объектов и обеспечить детальный разбор ICS-протоколов в ее зоне видимости. Ей не важно, что послужило причиной изменений, она контролирует «нормальный» режим работы, любое изменение такого режима, фиксируется в виде алерта, который дальше анализируется и предоставляется в центр сбора. Сама сессия проходила в хорошем темпе и запомнилась замечательной оговоркой ведущего по «Фрейду», который нескольких выступающих называл не Докладчиками, а Заказчиками, ну и аплодисменты сорвал молодой человек, попросивший микрофон, когда задавали вопросы и начал свой вопрос с представления Генеральная Прокуратура и далее фамилия, по моему, сам вопрос уже никто не слушал.
В целом повторюсь, мне мероприятие понравилось возможностью послушать разные точки зрения, понять тренды, формирующиеся на рынке, услышать мнение регуляторов, пообщаться с интеграторами, технологическими партнерами и заказчиками.  
World

Информационная безопасность критической инфраструктуры ("Автоматизация в промышленности, №2 2015)

Критическая инфраструктура состоит из физических и информационных объектов, сетей, услуг и ресурсов, повреждение или уничтожение которых существенно влияет на здоровье, безопасность или экономическое благосостояние граждан. Анализ текущей ситуации, показывает, что существуют возможности доступа из сетей общего пользования к критической инфраструктуре большинства российских компаний. Вопросам информационной безопасности критической инфраструктуры уделяется недостаточно внимания. Одним из инструментов, используемых в этой области, является программно-аппаратное решение ДатаДиод.
Ключевые слова: информационная безопасность критической инфраструктуры, сети общего пользования,  ДатаДиоды.

Информационная безопасность критической инфраструктуры (ИБКИ) - относительно новая тема, ставшая актуальной с развитием IP-сетей и началом повсеместного использования международных стандартов для задач управления технологическими объектами (энергетика, газ, нефтепереработка, транспорт, ЖКХ, водоотведение, химическая промышленность и т.д.) [1, 2]. Возникает вопрос: значит, правы консервативно настроенные эксперты, утверждая, что новые технологии – это зло, и достаточно было старых аналоговых систем, выделенных каналов передачи данных, а отдельные рабочие места для диспетчерского персонала и бумажные отчеты для руководства устраивали всех?
С точки зрения ИБКИ, безусловно, устаревшие системы управления, использующие нестандартные протоколы передачи данных и не присоединенные к сетям общего пользования, лучше всего защищены от внешних атак. Проблемы здесь возможны только за счет некорректной настройки самих систем управления, ошибок персонала при их эксплуатации, а также из-за нерегламентированного использования внешних накопителей (жесткие диски, флэш-карты и.т.д.). С другой стороны, меняется первичное оборудование, требования рынков и законодательства, и как следствие, меняются технологические и аналитические задачи, которые необходимо решать. Сохранить конкурентоспособность могут только те компании, которые активно внедряют новые технологии, а в ряде случаев устаревшее аналоговое оборудование просто снимается с производства, и его эксплуатация становится неоправданно дорогой.
Есть еще одна точка зрения: «Прогресс не остановить, но сети передачи данных могут быть изолированы физически». Да, такая мысль имеет право на существование, но проблема состоит в том, что за все надо платить. Объем информации, используемый в технологических сегментах сети, за последние 10 лет увеличился на несколько порядков, а функционал вырос многократно. Например, электронная почта стала одним из основных средств рассылки уведомлений о тех или иных событиях в системе диспетчерского управления. Современные промышленные контроллеры оснащаются программными Web-серверами, которые позволяют обеспечить наблюдаемость объекта для руководства и сервисного персонала в любой точке мира, где есть выход в Internet. Диагностика и обслуживание современного оборудования обеспечивается квалифицированным персоналом, который физически может находиться за сотни километров от оборудования и работать по удаленному каналу. Современные ситуационно-аналитические центры реагирования, аналитические и финансовые системы также требуют наличия доступа к данным технологических процессов. Платой, и весьма существенной, за изоляцию критической инфраструктуры будет необходимость ручного переноса информации и ограничения по использованию автоматического функционала, уже установленного оборудования и систем. Предположим, что можно построить систему, используя принцип физического выделения технологических сегментов сетей и утверждения набора организационно-технических регламентов, регулирующих ответственность и вопросы обмена данными между физически разделенными сегментами сетей. Но это потребует решения большого числа неявных задач, таких как:

  • наличие отдельных физических каналов передачи данных до каждого технологического объекта, отвечающих современным требованиям;

  • отсутствие возможности оперативного контроля ситуации для руководства и внешних компаний (ситуационно-аналитические центры, сервисные компании, МЧС);

  • наличие системы контроля ошибок и полноты данных при ручном переносе информации;

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

Конечно, здесь приведен далеко не полный перечень, но он уже вполне достаточен для обдумывания  целесообразности такого решения проблем ИБКИ.
Фактически сегодня мы находимся в ситуации, когда все крупные российские компании, имеющие инфраструктуру, которую можно отнести к разряду критической, используют сети общего пользования (физические каналы) или собственные бизнес-сети для передачи данных, формируемых внутри критической инфраструктуры. Для персонала, эксплуатирующего критическую инфраструктуру, ничего не изменилось. Сохранились старые регламенты, инструкции, система диспетчерского и технологического управления. Использование стандартов обеспечивает полную прозрачность сетевой инфраструктуры, и до момента возникновения аварий и проблем в системах управления вопросы ИБКИ вызывают негативную реакцию, что вполне оправдано. Регулирующие документы либо отсутствуют, либо находятся в стадии разработки.
Функционал систем, влияющих на уровень ИБКИ, требует введения определенных ограничений и регламентов. Обычно для любой компании работоспособность критической инфраструктуры является важнейшим показателем и все, что даже косвенно может повлиять на ее эксплуатацию, подвергается очень серьезному критическому анализу. Складывается ситуация, когда потенциальная угроза ИБКИ не воспринимается как нечто реальное и непосредственно угрожающее.
Далее следует вопрос: «Как же так? Все же очевидно!» Чаще всего те, кто произносят фразы, типа «все очевидно» или «абсолютно понятно», к сожалению, не могут внятно сформулировать, что же в действительности угрожает ИБКИ, и насколько опасны данные угрозы. Попробуем разобраться, в чем тут дело. Начнем с того, что сегодня специалисты по информационной безопасности в основной своей массе имеют богатый практический опыт реализации проектов в административной и финансовой сферах, а с проблемами и особенностями защиты критической инфраструктуры знакомы лишь в теории. В свою очередь технологи, ответственные за эксплуатацию и развитие критической инфраструктуры, весьма поверхностно представляют телекоммуникационную составляющую эксплуатируемых ими систем. В результате прямое взаимодействие специалистов заканчивается ничем, они просто не понимают друг друга - разная терминология, различные уровни и сферы ответственности. Для преодоления этого разрыва сформулируем общие принципы, на которых могло бы строиться такое взаимодействие. Будем использовать термины, понятные обеим фокусным группам специалистов.
1.                  Уровень доступа и действия всех технологов, ответственных за эксплуатацию критической инфраструктуры (КИ) строго регламентированы, как и действия банковских служащих, работающих со счетами клиентов.
2.                  Объем информации, передаваемой в системах управления, относительно незначителен, а вот гарантированная скорость передачи данных – критически важный параметр.
3.                  Промышленные контроллеры, в том числе устанавливаемые на объектах критической инфраструктуры, имеют встроенные Web-сервисы для предоставления возможности дистанционного мониторинга объекта.
4.                  Если объект находится под управлением автоматической системы (без участия человека), то обычно высокая надежность достигается дублированием (троированием) автономных программно-аппаратных комплексов (ПАК). Технологические оперативно-информационные системы в стандартном режиме просто мониторят работу и обеспечивают диагностику состояния таких ПАК. Они не вырабатывают управляющих воздействий. В этом случае предусмотрены процедуры изменения конфигурации ПАК как локально, так и дистанционно.
5.                  Если система управления автоматизирована (с участием человека), то четко определены уровни оперативно-диспетчерского управления, которые имеют полномочия и техническую возможность управлять объектами критической инфраструктуры.
6.                  Установлена четкая иерархия ретрансляции технологических данных по уровням оперативно-диспетчерского и технологического управления. В среднем число потребителей информации (пассивный просмотр данных, получение отчетов и BI-показателей) на порядок выше числа технологов, вовлеченных в процесс непосредственного управления процессами.
7.                  Определен четкий порядок информирования причастных должностных лиц при различных событиях и происшествиях от временного пропадания канала передачи данных до крупной аварии, повлекшей серьезные последствия. Большинство современных систем управления имеют встроенный SMTP сервер для рассылки соответствующих извещений по электронной почте.
8.                  В целом ряде случаев в качестве основного или резервного канала ретрансляции информации между уровнями оперативно-диспетчерского управления используется IP-облако компании или арендованные каналы передачи данных. Приняв систему управления в эксплуатацию от подрядчика, технолог уверен, что теперь любые изменения в архитектуре системы могут быть выполнены только по четко регламентированной процедуре заявок и отчетов о выполнении сервисно-эксплуатационных работ. При этом контроль изменения правил маршрутизации потоков данных на интеллектуальных телекоммуникационных устройствах у диспетчера отсутствует.
9.                  Антивирусные базы и стандартное ПО в технологических сегментах сетей обычно не обновляется, что обосновывается совместимостью ранее установленного ПО конкретного производителя с существующей операционной средой. Более того, зачастую производитель системы управления выпускает патчи (дополнения) к своему ПО (например, в случае выявления уязвимости по информационной безопасности), но оно не устанавливается, так как при этом необходимо провести полные функциональные испытания системы управления и внести изменения в организационно-методические документы.
10.              Диагностика и сервисное обслуживание устанавливаемого оборудования, в том числе и импортного, часто требует привлечения инженерно-технического персонала производителя для обеспечения его эксплуатации. Это влечет за собой необходимость организации удаленных рабочих мест и обеспечения внешнего доступа к объектам критической инфраструктуры.
11.              Растет число бизнес-приложений, использующих данные, формируемые внутри критической инфраструктуры. Это значит, что обеспечивается полноценное взаимодействие технологического и бизнес сегментов корпоративных IP сетей.
Разложив таким образом системы оперативно-диспетчерского и технологического управления, можно говорить о конкретных угрозах ИБКИ.
Одним из решений, позволяющих значительно повысить степень ИБКИ и одновременно обеспечить доступ к оперативно-технологической информации, является использование ДатаДиодов. Это программно-аппаратное решение, обеспечивающее  на физическом уровне одностороннее соединение сегментов IP-сетей с разным уровнем требований к безопасности. Сеть с более низким уровнем требований называется "черной", с более высоким уровнем – "красной". В основе решения лежит использование двух оптических карт. Оптическое волокно, используемое для передачи в сторону "черной" сети физически отсутствует, то есть данные не могут быть переданы в принципе.
В настоящее время для реализации ДатаДиода ведется поддержка широкого спектра технологических протоколов и приложений: IEC 60870-101, IEC 60870-103 (Siemens, ABB, Micom и др.), IEC 60870-104, IEC 61850, OPC 2.0, DNP3, ICCP, Modbus RTU, ABB (SCADA, SPA), OSIsoft PI Server, GE iHistorian, Wonderware Historian, ION, SATEC. Это позволяет обеспечить гарантированный доступ к технологическим данным, имея при этом гарантию неуязвимости самой критической инфраструктуры, так как физически канал доступа в защищаемый сегмент отсутствует.
Перечень внедрений ДатаДиодов достаточно широк: от оборонных до крупных энергетических компаний. В США, например, приняты стандарты, напрямую предписывающие использование ДатаДиодов для защиты критической инфраструктуры (NERC3). Международное агентство по атомной энергии МАГАТЭ использует их для контроля оперативной ситуации на атомных станциях. В России одной из первых начал применять данное решение холдинг ОАО «РусГидро».
Таким образом, ДатаДиоды можно считать современным эффективным инструментом для решения задач ИБКИ, гарантирующем сохранение управляемости объектами критической инфраструктуры, при любых внешних атаках, изменениях телекоммуникационной инфраструктуры, ошибках сервисных компаний и ошибочных (предумышленных или нет) действиях не оперативного персонала компании.
Основные характеристики:
·         Однонаправленное коммуникационное устройство:
o    аппаратная реализация (нет ПО, прошивок)
o    не может быть взломано
o    нет возможности онлайн-атак
o    нет потерь данных
o    большое количество внедрений по всему миру
·         Более 300 поддерживаемых приложений (FTP, TCP, UDP, SMTP, Kaspersky, MS SQL, Oracle, PI, WSUS и т.д.)
·         Поддержка промышленных протоколов, в том числе российских
World

Информационная безопасность критической инфраструктуры

Информационная безопасность критической инфраструктуры (ИБКИ) относительно новая тема, ставшая актуальной с развитием IP-сетей и началом повсеместного использования международных стандартов для задач управления технологическими объектами (энергетика, газ, нефтепереработка, транспорт, водоотведение, химическая промышленность и т.д.). Возникает сразу вопрос, значит, правы консервативно настроенные эксперты, что новые технологии – это зло, были старые аналоговые системы, выделенные каналы передачи данных, отдельные рабочие места для диспетчерского персонала и бумажные отчеты для руководства? С точки зрения ИБКИ, безусловно, устаревшие системы управления, использующие нестандартные протоколы передачи данных и не присоединенные к сетям общего пользования, в принципе безопасны, проблемы возможны только за счет некорректной настройки самих систем управления и ошибок персонала при их эксплуатации. С другой стороны, меняется первичное оборудование, требования рынков, решаемые технологические и аналитические задачи. Сохранить конкурентно способность могут только те компании, которые активно внедряют новые технологии, а в ряде случаев устаревшее аналоговое оборудование просто снимается с производства и его эксплуатация становится неоправданно дорогой. Есть еще одна точка зрения: «Ну, хорошо, прогресс не остановить, но сети передачи данных могут быть изолированы физически!». Да, возможная точка зрения, вопрос в том, что за все надо платить. Объем информации, используемый в технологических сегментах сети, за последние десять лет увеличился на несколько порядков, функционал вырос кратно, появились новые сервисы (уведомления руководства по электронной почте, вебсервера на контроллерах и прочее), диагностика и обслуживание оборудования квалифицированным персоналом по удаленному каналу, аналитические и финансовые системы, использующие данные технологических процессов, как исходную информацию, ситуационно-аналитические центры реагирования и т.д. Платой и весьма существенной, будет необходимость ручного переноса информации и ограничения по использованию автоматического функционала, уже установленного оборудования и систем. Как эксперт, могу предположить, что в принципе можно построить систему, используя принцип физического выделения технологических сегментов сетей и прописания набора организационно-технических регламентов, регулирующих ответственность и вопросы обмена данными между физически разделенными сегментами сетей. Только это потребует решения большого количества неявных задач, например:
• отдельные физические каналы передачи данных до каждого технологического объекта, отвечающие современным требованиям;
• отсутствие возможности оперативного контроля ситуации для руководства и внешних компаний (ситуационно-аналитические центры, сервисные компании, МЧС);
• система контроля ошибок и полноты данных при ручном переносе информации;
• система регистрации и контроля внешних носителей, предназначенных для переноса информации.
Конечно, здесь приведен далеко не полный перечень, но он уже вполне достаточен для того, чтобы серьезно задуматься о целесообразности такого решения проблем ИБКИ.
Фактически сегодня, мы находимся в ситуации, когда все крупные российские компании, имеющие инфраструктуру, которую можно отнести к критической, используют сети общего пользования (физические каналы) или собственные бизнес-сети для передачи технологических данных. Для персонала эксплуатирующего критическую инфраструктуру, ничего не изменилось. Сохранились старые регламенты, инструкции, система диспетчерского и технологического управления. Использование стандартов обеспечивает полную прозрачность сетевой инфраструктуры и до момента возникновения аварий и проблем в системах управления, вопросы ИБКИ вызывают негативную реакцию, что вполне оправдано. Регулирующие документы, либо отсутствуют, либо находятся в стадии разработки. Функционал систем влияющих на уровень ИБКИ требует введения определенных ограничений и регламентов. Обычно для любой компании работоспособность критическая инфраструктуры является важнейшим показателем и все, что даже косвенно, может повлиять на ее эксплуатацию, подвергается очень серьезному критическому анализу. Складывается ситуация, когда потенциальная угроза ИБКИ не воспринимается как нечто реальное и непосредственно угрожающее. Тут же следует вопрос: «Как же так? Все же очевидно!». Чаще всего те кто произносят фразы, типа «все очевидно» или «абсолютно понятно», к сожалению, не могут внятно сформулировать, что же в действительности угрожает ИБКИ и насколько опасны данные конкретные угрозы. Попробуем разобраться, в чем тут дело. Начнем с того, что сегодня специалисты по ИБ в основной своей массе имеют богатый практический опыт реализации проектов в государственной и финансовой сфере, а с проблемами и особенностями защиты критической инфраструктуры знакомы лишь в теории. В свою очередь, технологи, ответственные за эксплуатацию и развитие критической инфраструктуры весьма поверхностно представляют телекоммуникационную составляющую, эксплуатируемых ими систем. В результате, прямое взаимодействие специалистов заканчивается ничем, они просто не понимают друг друга, разная терминология, различные уровни и сферы ответственности. Чтобы преодолеть этот разрыв, сформулируем общие принципы, на которых могло бы строиться такое взаимодействие, используя термины понятные обеим фокусным группам специалистов:
1. Уровень доступа и действия всех технологов, ответственных за эксплуатацию критической инфраструктуры (КИ) строго регламентированы, также как и действия банковских служащих, работающих со счетами клиентов.
2. Объем информации передаваемый в системах управления КИ обычно незначителен, а вот гарантированная скорость передачи данных, критически важный параметр в таких системах.
3. Промышленные контроллеры, в том числе, устанавливаемые на объектах КИ имеют, встроенные WEB-сервисы, для предоставления возможности дистанционного мониторинга объекта.
4. Если объект КИ находится под управлением автоматической системы (без участия человека), то обычно высокая надежность достигается дублированием (троированием) автономных программно-аппаратных комплексов (ПАК). Технологические оперативно-информационные системы в стандартном режиме просто мониторят работу и самодиагностику таких ПАК, управляющие воздействия не предусмотрены. Безусловно предусмотрены процедуры изменения конфигурации ПАК, как локально, так и дистанционно.
5. Если система управления автоматизированная (с участием человека), то четко определены уровни оперативно-диспетчерского управления, которые имеют полномочия и техническую возможность управлять объектом КИ.
6. Предусмотрена четкая иерархия ретрансляции технологических данных по уровням оперативно-диспетчерского и технологического управления. В среднем, количество потребителей информации (пассивный просмотр данных, получение отчетов и BI-показателей) на порядок выше, количества технологов, вовлеченных в процесс непосредственного управления процессами.
7. Предусмотрен четкий порядок информирования причастных должностных лиц при различных событиях и происшествиях от временного пропадания канала передачи данных, до крупной аварии, повлекшей серьезные последствия. Большинство современных систем управления КИ, имеют встроенный SMTP сервер для рассылки соответствующих извещений по электронной почте.
8. В целом ряде случаев, в качестве основного или резервного канала ретрансляции информации между уровнями оперативно-диспетчерского управления используется IP-облако или арендованные каналы передачи данных.
9. Антивирусные базы и стандартное программное обеспечение в технологических сегментах сетей обычно не обновляется, что обосновывается совместимостью ранее установленного программного обеспечения конкретного производителя с существующей операционной средой. Более того, часто производитель системы управления выпускает патчи (дополнения) к своему ПО (например, в случае выявления уязвимости по ИБ), но оно не устанавливается, так как в случае его установки необходимо провести полные функциональные испытания системы управления и внести изменения в организационно-методические документы.
10. Приняв систему управления в эксплуатацию от подрядчика, технолог уверен, что теперь любые изменения в архитектуре системы, могут быть выполнены только по четко регламентированной процедуре заявок и отчетов о выполнении сервисно-эксплуатационных работ. Если в системе управления используются внешние IP-каналы передачи данных, то контроль изменения правил маршрутизации потоков данных на интеллектуальных телекоммуникационных устройствах у диспетчера отсутствует.
11. Растет количество бизнес-приложений, использующих данные систем управления КИ. Это значит, что обеспечивается полноценное взаимодействие технологического и бизнес сегментов корпоративных IP сетей.
Разложив, таким образом, системы оперативно-диспетчерского и технологического управления, можно говорить о конкретных угрозах ИБ, возникающих на каждом уровне при использовании той или иной телекоммуникационной архитектуры в системах управления КИ.
Основная задача, которая должна решаться системами ИБКИ – сохранение управляемости объектом КИ, при любых внешних атаках, изменениях телекоммуникационной инфраструктуры, ошибках сервисных компаний и ошибочных (предумышленных или нет) действиях внутреннего персонала компании.