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

Информационная безопасность в проектах по развитию Smart Grid

Развертывание интеллектуальных технологий Smart Grid с "встроенными" системами кибербезопасности является одной из ключевых задач, которая затрагивает все проекты по программе SGIG Министерства энергетики США.
Проекты по программе SGIG реализуют планы кибербезопасности (CSP) в течение двух последних лет. Каждый CSP должны обеспечить разумную защиту от широкого набора угроз, включая системные сбои в электрической сети в результате нарушения кибербезопасности. Для многих проектов планирование CSP является совершенно новой задачей, для многих интеграторов эта область лишь недавно стала одним из главных приоритетов. Эксплуатация, внедряемых систем начинает давать первые результаты, что работает хорошо, а что нет, и эти уроки имеют важное значение для успешной реализации CSP в дальнейших проектах.
Прогресс, достигнутый в области кибербезопасности является результатом совместной приверженности Министерства энергетики США и интеграторов, участвующих в реализации проектов по программе SGIG, к постоянному совершенствованию. Аудит показал, что проекты находятся на различных уровнях зрелости по кибербезопасности и предложения специалистов помогли интеграторам пересмотреть и улучшить их CSP. Министерство энергетики США начало вводить модель технологической зрелости (ES-C2M2) по кибербезопасности в электрической отрасли. Модель предоставит инструменты для улучшения CSP и использования лучших практик по кибербезопасности после завершения проекта. ES-C2M2 является инструментом для электроэнергетики и сетевых операторов, чтобы оценить свои возможности по кибербезопасности и приоритетность действий и инвестиций в улучшение кибербезопасности, она сочетает в себе элементы всех существующих решений по кибербезопасности, которые могут применяться последовательно в отрасли.


По материалам Progress Report II 2013, Smart Grid Investment Grant Program
World

Анализ развития Smart Metering 2013-2020: Приложения, рынки и стратегии

Что нас ждет в будущем на рынке Smart Metering?  Учитывая снижение стоимости счетчиков в глобальном масштабе,  крупные производители, в настоящее время, ищут новые источники доходов, и системы анализа измерительных данных становятся привлекательной возможностью получения таких доходов на постоянной основе.
По данным исследования, GTM Reseach, совокупные расходы от AMI аналитики, как ожидается, составит $ 9,7 млрд. к 2020 году. По мере развития рынка, поставщики решений смогут предлагать под ключ, аналитические системы без необходимости подгонять их под конкретного Заказчика. Даже сейчас,  уже начался процесс консолидации, поставщиков программного обеспечения, которые поглощаются более крупными конгломератами, так в 2012 году прошло приобретение EcoLogic Analitics и DataRaker  компаниями Landis + Gyr и Oracle соответственно.
AMI_Vendor_Tax_graphic2

Новый 142-страничный доклад GTM Reseach приводит детальный прогноз рынка Smart Metering, конкурентный анализ рынка оборудования и MDM систем, а также поставщиков интеграционных решений и платформ.

Доклад охватывает все аспекты AMI приложений, в том числе:

Отключение управления
Управление активами
Оптимизация напряжения
Системы планирования / прогнозирования
защита доходов
сегментация клиентов
Companies

По материалам GTM Reseach
World

Обзор инвестиций в SMART GRID в США за последние 4 года

Как гранты в $ 7,9 млрд повлияли на развитие Smart Grid в США

map


В октябре 2009 года Министерство энергетики США выбрало 99 проектов по развитию Smart Grid на общую сумму $ 3 400 000 000, для финансирования из федерального бюджета. Проекты также предусматривали $ 4,5 млрд. частного финансирования, чтобы соответствовать, требованиям Программы предоставления Инвестиционных Грантов (SGIG).
Теперь, спустя четыре года, можно провести анализ, как большинство из этих денег было потрачено, и то, какие результаты были достигнуты, по программе SGIG (SGIG Progress Report II). Наряду с этим, приходит понимание, что 7,9 миллиарда долларов по-прежнему представляет собой "относительно небольшой первоначальный взнос из сотен миллиардов долларов необходимых электроэнергетике США, чтобы полностью модернизировать электрические сети в течение следующих нескольких десятилетий."
Действительно, американское энергетическое агентство (EPRI) прогнозирует, что американским компаниям необходимо будет инвестировать примерно от $ 17 до $ 24 миллиардов в год для достижения долгосрочной окупаемости от $ 1,3 до $ 2 трлн к 2030 году. Об этом же свидетельствуют отчеты Министерства энергетики США, а также независимые оценки таких проектов.
Но с большинством проектов по программе SGIG еще много неясного. Они находятся в стадии выполнения и окончательные эффекты еще не достигнуты. Министерство энергетики США пересмотрело расходы по различным категориям технологий, а также некоторые ключевые моменты, по категориям технологий, на основе уже полученных результатов от их реализации.
По состоянию на конец марта 2013 года, Министерство энергетики США перевело более чем на $ 3 млрд из своих первоначальных обязательств, в результате чего общие затраты составили более $ 6 миллиардов. Проекты были распределены по крупным коммунальным компаниям, небольшим муниципальным и сельским кооперативам коммунальных услуг, и группе компаний потребителей.
Большинство из этих проектов планируется завершить к концу 2013 года и продолжить анализ данных и отчетности до 2015 года. Однако из-за смягчающих обстоятельств (например, задержек связанных с погодой), Министерство энергетики США предоставляет один год, дополнительно для ряда проектов; которые планируется завершить к 2014 году, при продолжении контроля отчетности до 2016 года.
Из 99 проектов 76 (около 70%) находятся в высокой степени готовности, в то же время несколько проектов существенно отстают:
Percent

Проводя анализ по реализуемым категориям технологий, мы видим, что проекты по внедрению систем Smart Metering, получившие самую большую долю средств по программе SGIG, потратили почти все выделенные средства, а вот проекты по оптимизации распределения и передачи электроэнергии далеко позади.
Costs

Тот факт, что системы Smart Metering получили большую часть финансирования не вызывает удивления, так как данное направление сейчас переживает бурный подъем во всем мире. На сегодняшний день в рамках 65 передовых проектов систем Smart Metering при поддержке программы SGIG установлено 14 200 000 смарт-счетчиков, 92 процентов из 15,5 млн., запланированных дату завершения программы SGIG. Что является значительная долей из 46 000 000 смарт-счетчиков установленых в общенациональной сети США по состоянию на прошлый месяц, всего необходимо установить 65 миллионов смарт-счетчиков к 2015 году.
Devices

Около $ 3920 млн. было потрачено по состоянию на март 2013 года, непосредственно на счетчики, средства связи, системы управления измерительными данными. В свою очередь, энергокомпании прогнозируют, существенную экономию от внедрения, за счет снижения эксплуатационных расходов, возможностей управления подачей электроэнергии, и других функций, которые обеспечивают системы Smart Metering.
Deployment

С другой стороны завершение проектов по системам Smart Metering еще потребует серьезной работы. Причины простые, в том числе основная «Связь и вопросы интеграции систем». Смарт-счетчики различных производителей должны эффективно взаимодействовать с системами управления Заказчика.
Communication

Кроме того, проблемой стало доказать потребителям выгодность использования современных тарифов с переменными ставками, в зависимости от времени дня или нагрузки сети. По состоянию на март, в общей сложности $ 510 млн были потрачены на развертывание клиенто-ориентированных систем, большинство из которых строятся по технологии веб-портала.
Было проведено одиннадцать исследований потребительского поведения для оценки привлекательности различных тарифов. Тарифы могут варьироваться на 30 процентов и более для некоторых планов, по существу без изменения объема потребляемой электроэнергии, полученные данные показывают, насколько сложным и ненадежным является создание экономически эффективных программ клиента с помощью умной энергосети.
Оптимизация распределения и передачи электроэнергии по транспортной сети гораздо более предсказуема с точки зрения затрат и результатов расчетов, но здесь тоже пока много вопросов из-за низкой готовности проектов.
В отчете Министерства энергетики США очень много данных, которые могут быть интересны для изучения, в том числе управление напряжением и реактивной мощностью (Вольт / VAR системы) в распределительных сетях, развертывание синхронизированных систем с соседними странами, а также других проектов в рамках своей компетенции. Считайте, что это снимок масштабной программы правительства США, которое все еще ожидает окончательных результатов от его широких воздействий на системы электроснабжения страны.

По материалам GTM Reseach.
World

Технологии для метрологии и информационной безопасности

МЕТРОЛОГИЯ И ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ
ЧТО ОБЩЕГО?

В сфере информационной безопасности есть такое понятие «комплаенс». Этот термин подразумевает контроль выполнения пользователями и приложениями корпоративной сети некой последовательности действий, предусмотренных регламентирующими документами. Особенно это востребовано в крупных финансовых организациях. Метрология по сути своей тоже обеспечивает государственный контроль за проведением измерений путем четкой регламентации всех действий, имеющих отношение к получению результатов измерений. Сегодня программное обеспечение стало неотъемлемой частью измерительных систем и классическими методами обеспечить должный уровень контроля проведения измерений становится невозможно.
Программное обеспечение в составе измерительных систем предназначено для обработки, хранения, предоставления и визуализации измерительных данных. Измерительные данные – это один из видов информации. Необходимость ее обработки и визуализации, сегодня, ни у кого сомнений не вызывает. Более того, чем более качественно информация будет систематизирована, тем больший эффект от ее использования может быть достигнут.
Чтобы решить возникающее противоречие, давайте подробнее рассмотрим жизненный цикл измерительных данных, как вида информации. Его можно разделить на три этапа:
1. измерения;
2. передача информации;
3. хранение и обработка.
Непосредственно измерительные процессы протекают в специализированном оборудовании. Обычно поверка программного обеспечения вне оборудования не требуется, так как определены алгоритмы работы на физическом и логическом уровне. Подробное описание этих алгоритмов обычно приводится в метрологической документации на прибор. Утверждается методика поверки оборудования.
Итак, измерения проведены, далее измерительная информация передается (чаще всего по запросу) по каналам передачи данных и попадает в хранилище данных. Здесь информация становится доступной потребителям (функциональным пользователям, внешним системам). На этом этапе вызывающему приложению необходимо отсылать реквизиты вызываемому приложению, в нашем случае программному обеспечению специализированного прибора, описанного выше. Здесь возникают первые угрозы для измерительных данных. Получив доступ к пользовательским данным, возможно, получить бесконтрольный доступ и нарушить установленный порядок работы измерительной системы.
Следующий этап – хранение и обработка данных. Он осуществляется уже программным обеспечением верхнего уровня, где риски доступа и изменения измерительных данных уже столь многовариантны, что пытаться их анализировать здесь не имеет никакого смысла.
Долгое время вопросам метрологического обеспечения верхнего уровня (программного обеспечения) не уделялось должного внимания. В результате сложилась фактическая ИТ-инфраструктура с устоявшимися бизнес-процессами и уже внедренными решениями, одномоментное изменение, которых невозможно. В свою очередь, контроль работы алгоритмов оперирующих с измерительными данными должен осуществляться в реальном времени.
Рассмотрим риски, которые должны быть исключены в процессе метрологического контроля и надзора. Далеко не полный их перечень, приведен ниже:
• ошибки персонала;
• преднамеренные действия по изменению измерительной информации;
• качество сервиса;
• ошибки программного обеспечения;
• нарушения методологии (МВИ) работы;
• искажения отчетности.
Классическое решение проблемы с использованием иерархии персональных паролей в системе, к сожалению, уже не является достаточным. Каждый сервер может администрироваться несколькими сотрудниками, зачастую не имеющими прямого отношения к обслуживанию непосредственно измерительной системы. Распределенные системы хранения данных от ведущих производителей, обеспечивают высокую надежность, но определить при этом, на каком конкретном физическом устройстве, в данный момент, хранятся измерительные данные также невозможно.
Возникает вопрос, а существуют ли в принципе, инструменты, с помощью которых, поставленная задача может быть решена? Да существует! Просто надо немного отвлечься от метрологии и посмотреть решения в сфере информационной безопасности. Попытаемся проанализировать, что общего у таких задач как:
• защита от мошенничества и неконтролируемой утечки информации в финансовой сфере;
• финансовый и операционный контроль;
• контроль качества эксплуатации ИТ-систем;
• предотвращение отказов, вызванных ошибками программного обеспечения;
• метрологический контроль и надзор.
При более внимательном рассмотрении, все эти задачи могут решаться с помощью одних и тех же инструментов, которые включают в себя:
• построение модели состояния данных;
• механизмы и методы контроля;
• индикаторы;
• автоматические правила (алгоритмы).
В финансовой сфере такие системы контроля уже давно и успешно используются на практике. Более того компании, чьи акции торгуются на международных торговых площадках, в обязательном порядке, используют аналогичные системы контроля, в соответствии с действующими нормативными документами. Специально для этой статьи я подобрал краткий перечень действующих, на сегодняшний день, нормативных документов для различных областей деятельности:
• СТО БР ИББС-1.0-2010, Россия
– требует определить процедуры мониторинга и анализа данных регистрации, действий и операций, позволяющие выявлять неправомерные или подозрительные операции и транзакции.
• Sarbanes-Oxley - закон Сарбанес-Оксли ,США
– коммерческие компании и организации обязаны осуществлять эффективный внутренний информационный контроль
• Gramm–Leach–Bliley ׂ-Закон Грэма-Лича-Блилей, США
– требует от финансовых организаций принятия мер для регистрации доступа к информационным системам
• Basel 2 legislation, «Базель 2»
– требует создания эффективных служб внутреннего контроля и управления рисками
• HIPAA - Закон об отчетности и использовании данных в сфере страхования здоровья ,США
– требует принятия мер для регистрации и отслеживания деятельности медицинских учреждений
Как видно из приведенного перечня, Российский Центробанк первым в Российской Федерации регламентировал использование автоматизированных систем контроля в банковской сфере.
Теперь сформируем модель отношений в области измерительных систем, которая позволит слова «поверка алгоритма» из набора слов превратить в нечто конкретное. Сегодня Государственный реестр средств измерений – это громадный бумажный архив. Чтобы внести изменения в документацию, требуется подготовить определенный перечень бумаг, их подписать, утвердить, представить и только после этого использование модифицированного средства измерений становится легитимным. Когда мы говорим об современных распределенных измерительных системах, изменения происходят ежедневно и в результате требования, которые по объективным причинам, выполнить нельзя, порождают ситуацию, когда они просто не выполняются до выявления фактов несоответствия при очередной проверке и то, если проверка их выявляет. Проверяющие часто не в состоянии объехать 100% измерительных комплексов, а эксплуатирующая организация знает, что где и когда показывать. В результате, в случае с распределенными измерительными системами, текущая информация в Государственном реестре и реальная на объектах, совпадает не более чем в течение месяца после внесения документов в Государственный реестр средств измерений! В корне изменить ситуацию может создание электронного реестра измерительных систем, хотя мое мнение, что на современном этапе развития информатизации общества, весь Государственный реестр средств измерений должен быть электронным. Создав Государственный электронный реестр средств измерений, помимо требований, эксплуатирующим компаниям будут предоставлены инструменты для актуализации текущего состояния в предусмотренном порядке. Возможно, определить градацию данных, которые могут быть актуализированы непосредственно эксплуатирующей организацией и данных актуализируемых через ГЦИ СИ. В рамках статьи подробно описывать методологию перехода на электронный реестр и порядка работы с ним не имеет никакого смысла. При этом сам по себе электронный реестр это просто изменение формы хранения информации. Следующий шаг, снижение рисков описанных выше. Ростехрегулирование должно подготовить и выпустить документ, аналогичный СТО БР ИББС-1.0-2010, который, в том числе, должен определить положение о государственном реестре программ контроля работы алгоритмов в измерительных системах.
Каждое новое средство измерений, не говоря уже об распределенных измерительных системах, сегодня содержит серьезный объем программного обеспечения, влияющего на результаты измерений. И тут два пути:
• ограничить сферу метрологического контроля только физическими измеренными параметрами, а контроль остального предоставить финансовым системам (для них это величина – фактический объем товара важный показатель, влияющий на финансовые параметры), но тогда надо менять все установившиеся процедуры информационного обмена;
• формировать набор новых инструментов, позволяющих обеспечить реальный метрологический контроль измерительных данных, от прибора до отчета.
World

Виртуализация проверок АИИС КУЭ на Оптовом Рынке Электроэнергии. Новые вызовы

В начале 2012 года, когда собирали предложения по темам для проведения НП "НТС ЕЭС", я предложил посвятить одно заседание информационной безопасности. В тот момент конечно речь шла о системах Smart Metering. По всей стране были запущены пилоты, тендерная документация большинства МРСК содержала требования по наличию возможности управляющих воздействий, формальных единообразных правил не существовало (как впрочем не существует и сейчас), поэтому вопросы защиты от несанкционированных действий в Smart Metering очень актуальны.
В процессе подготовки, к выступлению, я провел анализ документов по информационной безопасности европейских регуляторов, корпоративных объединений (IDIS), производителей коммуникационных решений для Smart Grid и Smart Metering (PPC), непосредственно вендоров (Landis+Gyr, Iskraemeco). Не вдаваясь в подробности, общий вывод неутешительный. Пока единой концепции информационной безопасности для Smart Metering в Европе не существует. Единственная страна Евросоюза принявшая официальный документ, хоть как-то определяющий требования к информационной безопасности в системах Smart Metering – это Германия, но этот документ определяет лишь часть необходимых требований и вызывает нарекания, как со стороны специалистов, так и со стороны производителей. Более внятно концепция информационной безопасности изложена в документах IDIS (уровень счетчиков и концентраторов), но при этом каждый производитель оборудования и решений готовит свою концепцию, исходя из опыта текущих проектов.
В рамках консалтинговой деятельности, я сотрудничаю с целым рядом производителей решений в области информационной безопасности и производителями оборудования и решений Smart Metering. Нам удалось организовать несколько плодотворных семинаров во время прохождения последней выставки Smart Metering/Billing в Амстердаме, в процессе которых у наших партнеров появилась уникальная возможность получить информацию из «первых» рук.
Если суммировать выше сказанное, становится понятно, почему получив предложение выступить по тематике мониторинга и дистанционных проверок АИИС КУЭ Субъектов ОРЭМ, мне не пришлось долго собирать материалы. Большинство решений зависит не от конкретной задачи, а от потенциальной угрозы, которые весьма схожи.
Итак начнем с определения самого понятия риска:
Риск – это комбинация вероятности события и его последствий (ISO/IEC Guide 73).
Следствие:
Любые действия приводят к событиям и последствиям, которые могут представлять собой как потенциальные «положительные» возможности, так и «опасности»
Меняя порядок проведения проверок АИИС КУЭ Субъектов ОРЭМ, мы совершаем действие, которое в соответствии с нашим «следствием» помимо «положительных» возможностей принесет нам и потенциальные «опасности». Попробуем сформулировать основные опасности:
1. Ошибки персонала
2. Преднамеренные действия по сокрытию (изменению информации)
3. Утечка информации
4. Ошибки программного обеспечения
5. Некорректная работа программно-аппаратных комплексов
6. Нарушения методологии работы
7. Искажения отчетности
Это конечно далеко не полный перечень рисков, какие-то из них могут быть более опасными, какие-то менее, причем для каждой задачи, каждого Заказчика опасность одних и тех же рисков разная. Поэтому проектирование системы информационной безопасности всегда начинается с построения конкретной модели угроз.
Целый ряд происшествий по всему миру, включая Россию, наглядно демонстрирует реальную опасность беспечного отношения к информационной безопасности при реализации тех или иных проектов. Современные технологии очень удобны, но часто настолько же уязвимы для внешних воздействий.
Итак, начнем с детального разбора «очевидных» требований, параллельно будем уточнять формулировки и предлагать инструменты, которые позволят нам эти требования безопасно реализовать.
Для Субъекта ОРЭМ, переход на дистанционные проверки и мониторинг АИИС КУЭ со стороны КО, требует, прежде всего разработки нового раздела ТРП на АИИС КУЭ или отдельного ТРП на информационное взаимодействие. Любая крупная компания имеет набор требований по организации доступа в ведомственную сеть внешних пользователей, поэтому придется учесть внутрикорпоративные требования и найти решение, которое им бы удовлетворяло, затем необходимо будет учесть типовые решения и сценарии, которые в будущем утвердит КО. Таким образом, новый Раздел ТРП (отдельный ТРП) необходимо будет согласовать как внутри компании, так и с КО.
Теперь рассмотрим инструменты, которые могут быть использованы при установлении соединения между сетью КО и сетью Субъекта ОРЭМ. Физический разрыв и передача данных в оффлайн почтой, подробно рассматривать не будем. Эта система действует сейчас, она безопасна, но не очень удобна. Классическое решение использование Фаерволов. Это активное сетевое оборудование, содержащее набор правил, определяющих порядок доступа в сеть. Проверенная технология, автоматизированное и гибкое решение, которое широко используется сегодня, как в корпоративных сетях, так и в сетях общего доступа. Минус только один, если правила противоречат друг другу или не описывают весь перечень опасностей (человеческий фактор) или у кого-то есть возможность внести несанкционированные изменения в них (утечка информации), то любой даже самый сложный фаервол может быть обойден, что уже происходило неоднократно. ДиодДанных – физическое устройство, гарантирующее на физическом уровне, однонаправленный поток данных из одного сегмента IP-сети в другой. ДиодДанных не может заменить фаервол, но для определенных задач, где требуется гарантированная защита инфраструктуры (правительственные структуры, военные, ядерная энергетика, энергетика, промышленность) является оптимальным решением. В каждом сегменте IP-сети устанавливается специализированный прокси-сервер, который эмулирует двунаправленную работу IP-сети, а с другой стороны передает/принимает пакеты для ДиодаДанных. Для нашего случая оптимальной будет конфигурация, используемая для аудиторских и сервисных компаний. Основной канал (мониторинга) идет через ДиодДанных, а второй канал разомкнут. При проведении дистанционных проверок, второй канал замыкается, в рамках специальной процедуры проверки, а затем после окончания работ, опять разрывается. Данное решение имеет опыт эксплуатации уже более десяти лет и серьезный референс во всех вышеперечисленных отраслях. Его активно используют европейские регуляторы энергорынков, атомные станции и МАГАТЭ, в 2011 году ОАО «Русгидро» включило ДиодДанных в свое типовое решение для верхнего уровня информационных сетей Гидростанций.
Следующий шаг, внешний удаленный рабочий стол КО при проведении дистанционных проверок. Субъект ОРЭМ начал процедуру проверки, следовательно, замкнул второй канал, обеспечив физическую возможность доступа в свою сеть. Соответственно с этого момента и на весь период проведения проверки существует потенциальная опасность хакерской атаки сети Субъекта ОРЭМ, причем пострадать могут и Субъект ОРЭМ и КО одновременно. Следовательно, по этому каналу необходимо идентифицировать не только логические параметры соединения, но и физические, например местоположение, устройство, операционную системы, установленные приложения, пользователь. Если хотя бы один из этих параметров не будет соответствовать предопределенным заранее, то в сеансе связи пользователю будет отказано, и он никаким образом не сможет попасть в защищаемую сеть. Универсальным инструментом, не зависящим от типа используемого Субъектом ОРЭМ, активного сетевого оборудования, для такого контроля является продукт Portnox. Любое подключение к вашему серверу, не важно, через какие средства виртуализации оно будет проведено, можно однозначно идентифицировать и принять решение о его допустимости. Задержки работы прикладного программного обеспечения исключены. Portnox имеет богатый референс по всему миру, гибкие средства конфигурации и настройки, не требует установки агентов.
Пройдена физическая идентификация, необходимо начать работать с Приложениями и Базами Данных. К сожалению, просто предоставить КО пароль на чтение, тоже недостаточно. Во-первых, часто пароли не меняются с момента внедрения системы, их знают, в том числе, ныне не работающие сотрудники, нет никаких гарантий, что используя логический канал для КО, кто-то не попробует воспользоваться другими паролями. А также есть целый ряд вопросов, ответы на которые могут потребоваться Субъекту ОРЭМ в любой момент:
• Какие операции выполнял внешний специалист в рамках предоставленного доступа ?
• Кто санкционировал предоставление доступа к конкретным системам ?
• Как быстро можно предоставить безопасный доступ к важной системе при её отказе?
• Когда менялись административные пароли к важным системам последний раз?
• Сколько людей могут воспользоваться жестко закодированными паролями в ваших приложениях?
Инструментом, который поможет Субъекту ОРЭМ всегда контролировать ситуацию является продукт PSM. Общая архитектура решения предполагает, что все пользователи, приложения и базы данных в сети взаимодействуют через PSM. Пользователь однократно входит в систему через PSM, с этого момента, он может подключаться к авторизованным для него устройствам без ввода каких-либо паролей. PSM используется как прокси-сервер, для установления соединений вместо предоставления пользователям реквизитов для входа, обеспечивается запись и воспроизведение сессий и их надежное, долговременное хранение в Цифровом хранилище. Решение имеет солидную историю на рынке, включая целый ряд внедрений в России.
Встав на точку зрения Субъекта ОРЭМ, мы сформулировали ряд потенциальных угроз и методов их нивелирования. Теперь рассмотрим эту же ситуацию с точки зрения КО. Сначала детализируем требования в исходном слайде. «Обеспечить выделенный канал Internet без корпоративных ограничений и без возможности входа в корпоративную сеть». Фактически это требование предполагает, что только сам пользователь будет определять политики безопасности на рабочих местах, подключенных к этому сегменту сети, что само по себе некорректно, при этом надо учитывать, что если будет использоваться активное оборудование корпоративной сети, то только логически будет запрещен вход в корпоративный сегмент сети, таким образом, в любом случае будет существовать потенциальная угроза для корпоративной сети. «Ежедневный мониторинг АИИС КУЭ Cубъектов ОРЭМ с выделением «нарушителей», что означает постоянное соединение сети Субъекта ОРЭМ и КО.

Теперь попробуем уточнить формулировки требований к сети КО:
• Создается отдельный сегмент корпоративной сети
• Определяются политики безопасности для данного сегмента
• Правила взаимодействия данного сегмента с корпоративной сетью (например однонаправленная трансляция данных)
• Определяются условия подключения к данному сегменту Субъектов ОРЭМ (перечень технических и организационных мероприятий, которые должны быть проведены на стороне Субъекта)
Организационные меры, которые необходимо проработать КО:
• Разрабатывается, согласуется и утверждается проект организации выделенного сегмента информационной сети КО, в целях мониторинга, анализа и контроля АИИС КУЭ Субъектов ОРЭМ
• Выполняются работы по созданию и сдаче в эксплуатацию выделенного сегмента
• Разрабатываются и утверждаются:
– перечень событий, форм, данных и отчетов АИИС КУЭ Субъектов ОРЭМ, которые будут подвергаться онлайн-мониторингу со стороны КО
– перечень функций АИИС КУЭ Субъектов ОРЭМ, которые должны быть доступны КО при проведении дистанционных проверок
– регламент проведения дистанционных проверок
– типовые решения для систем безопасного информационного взаимодействия (БИВ) Субъектов ОРЭМ с КО

Требования КО к Субъектам ОРЭМ, в этом случае, будут звучать так:
• В документации на АИИС КУЭ предусмотреть сценарии удаленного доступа со стороны КО (внести изменения в ПМИ, ТЗ, ТРП, протоколы предварительных испытаний), в соответствии с требованиями КО по мониторингу и проведению дистанционных проверок
• Доработать и сдать в постоянную эксплуатацию программное обеспечение АИИС КУЭ
• Разработать, согласовать и утвердить проект системы БИВ с КО
• Внедрить систему БИВ и предоставить КО результаты испытаний системы при вводе в постоянную эксплуатацию
Окончательно схема информационного взаимодействия КО с Субъектами ОРЭМ будет выглядеть следующим образом. По однонаправленному каналу (ДиодДанных) КО в онлайн режиме получает данные мониторинга от Субъектов ОРЭМ. Наступает момент проведения проверки, подается заявка, замыкается второй канал передачи данных, проходит физическая идентификация в сети Субъекта, получаются права доступа, проводятся работы, фиксируется окончание работ, канал размыкается. На каждом этапе работ, ответственный со стороны Субъекта ОРЭМ направляет отчеты с ЭЦП для КО.
Наиболее сложный вопрос состоит в том, что делать, если Субъект ОРЭМ выполнил все требования КО, но не согласен с результатом проверки. Внутри своей сети Субъект может делать с данными что угодно уже после окончания дистанционной проверки. Арбитром в такой ситуации может выступить НП «Совет Рынка». Хотя для этой роли ему тоже нужен инструмент внутреннего контроля. Таким инструментом является система Intellinx –уникальное решение для обнаружения и предотвращения злоупотреблений.
Система обеспечит:
• Полное воспроизведение сеансов работы пользователей
• Гибкая и быстрая поисковая система - “как Google”
• Предопределенные правила для распознавания нарушений в порядке работы пользователей в реальном времени
• Динамические профили и рейтинговые модели
• Новые правила могут быть определены и использованы пост-фактум – для расследования событий в прошлом
• Аналитический инструментарий для расследования событий
• Динамические отчеты и графики
• Инструментарий для анализа и минимизации ошибочных результатов
В основе работы системы лежит патентно-защищенная технология прослушивания и анализа сетевых пакетов. Не требует установки каких-либо компонент на клиенте или на сервере, не влияет на производительность серверов или сети. Данные записываются в закодированном и защищенном от изменений формате. Большое количество внедрений, как гарантия надежной и качественной работы.
Имея отчетность, которую подготовит система, специалисты НП «Совет Рынка» смогут однозначно определить проводили ли Проверяющие (представители КО) с данными Субъекта ОРЭ несанкционированные действия или нет, если да, то результаты проверки должны быть аннулированы и назначена новая проверка, если нет, то за Субъектом ОРЭМ всегда остается право идти в суд и там пытаться оспорить результаты проверки.
Новая форма взаимоотношений Субъекта ОРЭМ и КО также потребует нового документа, который бы формально регулировал эти взаимоотношения. Назовем его условно Соглашение о присоединении к системе мониторинга. Соглашение должно содержать:
• Перечень лиц, уполномоченных Субъектом ОРЭМ на взаимодействие с КО по вопросам мониторинга и дистанционных проверок
• Бланки информационного взаимодействия
• Регламент рассмотрения заявок Субъектом ОРЭМ и КО
• Перечень технических и программных средств, используемых Субъектом ОРЭМ и КО
• Информационные шаблоны подтверждений Сторон в процессе взаимодействия
• Условия прекращения работ по Соглашению по инициативе одной из Сторон
В процессе эксплуатации системы мониторинга, будет возникать целый ряд ситуаций, требующих формализации на регламентном уровне. Некоторые из них можно предвидеть уже сейчас, некоторые выявятся только в процессе работы.
В заключении, хочу отметить, что дистанционные проверки и онлайн мониторинг АИИС КУЭ - естественный шаг в развитии коммерческого учета на ОРЭ, но как любой новый шаг, он порождает новую систему взаимодействия КО и Субъектов ОРЭМ. Новая система требует определить технологические, организационные, методические и юридические аспекты.
Данное выступление, не претендуя на полноту, освещает все эти аспекты, а также показывает, что сегодня, у нас достаточно инструментов для организации дистанционных проверок и онлайн мониторинга АИИС КУЭ на ОРЭ. Ориентировочно, около года уйдет на выстраивание системы мониторинга и дистанционных проверок на ОРЭ, затем еще около года будет накапливаться опыт эксплуатации. Ну а в дальнейшем можно предположить развитие системы на новый уровень, например переход на сбор коммерческой информации непосредственно КО, с предоставлением этой информации Субъектам ОРЭМ.
World

21 шаг на пути к безопасности SCADA

Ниже приведен перевод действующего в США документа, содержащий требования к информационной безопасности SCADA. Документ был подготовлен еще в 2001 году, по заказу Президентского Совета «Защита критической инфраструктуры». Он дает возможность системно взглянуть на проблемы критической инфраструктуры с точки зрения информационной безопасности.

Системы диспетчерского управления и сбора данных (SCADA) содержат компьютеры и приложения, которые выполняют ключевые функции в обеспечении основных услуг и товаров (например, электричество, природный газ, бензин, вода, отходы - обработка, транспортировка) для населения. Как таковые, они являются частью критической инфраструктуры страны и требуют защиты от различных угроз, которые существуют в кибер-пространстве. Сбор и анализ данных, дистанционное управление оборудованием, таким как насосы, клапаны, выключатели, системы регулирования, SCADA сети обеспечивают высокую эффективность и широко используются. Тем не менее, их внедрение приводит к появлению новых угроз информационной безопасности. Сети SCADA были первоначально предназначены для увеличения функциональности, при этом мало внимания уделялось безопасности. Как результат, эффективность, надежность гибкость и безопасность распределенного управления / SCADA не вызывают сомнений, а вот вопросы безопасности самих систем решены не на должном уровне. Это делает некоторые сети SCADA потенциально уязвимыми к нарушению обслуживания, процессам перенаправления или манипуляций оперативными данными, которые могут привести к серьезным сбоям в критической инфраструктуре страны. Документ является обязательным для всех организаций, государственных и коммерческих, при выполнении работ по обеспечению безопасности сетей SCADA, как составной части критической инфраструктуры страны. Департамент защиты критической инфраструктуры при Президенте, а также министерство энергетики, разработали шаги, описанные здесь, чтобы помочь любой организации улучшить безопасность своей сети SCADA. Эти шаги являются необходимыми, но не достаточными. Однако, их необходимо предпринять для улучшения защиты сетей SCADA. Шаги делятся на две категории: конкретные меры по улучшению реализации, и действия, которые необходимо реализовать, а также основные процессы управления и политики.
Президент Буш создал Президентский Совет «Защита критической инфраструктуры» в октябре 2001 года распоряжением 13231 для координации всех федеральных мероприятий, связанных с защитой информационных систем и сетей, поддерживающих критически важных объектов инфраструктуры, в том числе:
✶ федеральных министерств и ведомств
✶ компаний частного сектора, которые работают в критических инфраструктурах
✶ критических инфраструктур государства и местных органов власти
✶ безопасности, связанных с национальными программами.
А также, повышения энергетической надежности, и оказания помощи при ликвидации чрезвычайных ситуаций.

Следующие шаги ориентированы на конкретные действия, которые необходимо принять для увеличения степени безопасности сетей SCADA:
1. Определить все подключения к сети SCADA.
Провести тщательный анализ возможных рисков и необходимость каждого подключения к сети SCADA. Разработать комплексную архитектуру всех подключений к сети SCADA, с оценкой степени защищенности этих связей. Выявить и оценить следующие типы соединений:
• Внутренних локальных и глобальных сетей, в том числе бизнес-сетей
• Интернет
• Беспроводные сетевые устройства, в том числе спутниковые каналы связи
• модем или коммутируемого подключения
• Соединения с деловыми партнерами, поставщиками или регулирующими органами
2. Отключите ненужные подключения к сети SCADA.
Для обеспечения высокой степени безопасности систем SCADA, изолировать сети SCADA от подключения к другим сетям насколько это возможно. Любое соединение с другой сетью представляет угрозу безопасности, в частности, если соединение создает путь от или к сети Интернет. Хотя прямые связи с другими сетями эффективный и удобный способ передачи важной информации, часто просто не стоит рисковать; изоляция SCADA сети должна быть главная цель, чтобы обеспечить необходимую защиту. Такие стратегии, как использование «демилитаризованной зоны» (DMZ) и хранилищ данных могут обеспечить более надежный способ передачи данных из сети SCADA в бизнес-сети. Однако они должны быть разработаны и внедрены, чтобы не допустить появления дополнительных рисков при неправильной конфигурации.
3. Оценка и укрепление безопасности любых оставшихся подключений к сети SCADA
Проведение тестов на проникновение и анализ уязвимостей любых оставшихся подключений к сети SCADA, чтобы оценить защиту конфигурации, включающей эти подключения. Используйте эту информацию в сочетании с разработкой эффективной стратегии защиты для любых подключений к сети SCADA. Уровень безопасности сети SCADA, определяется уровнем безопасности ее самого слабо защищенного подключения, это важно для реализации брандмауэров, системы обнаружения вторжений (IDS) и других соответствующих мер безопасности в каждой точке подключения. Конфигурировать Правила брандмауэра необходимо как можно более конкретно. Например, даже доступ для независимого системного оператора (ISO) не должен быть предоставлен без ограничений. Каждое подключение должно обосновываться необходимостью для соединения с определенными компонентами системы SCADA. Стратегически разместить IDS, в каждой точке подключения, чтобы предупредить персонал службы безопасности при потенциальном нарушении безопасности сети. Менеджмент организации должен понимать и принимать ответственность за риски, связанные с каким-либо подключением к сети SCADA.
4. Сервера SCADA систем, удаление или отключение ненужных служб
SCADA серверы управления построены на коммерческих операционных системах или операционных системах с открытым исходным кодом и могут подвергаться атаке. Во-первых, необходимо, удалить или отключить неиспользуемые службы и сетевые домены для снижения риска прямых атак. Это особенно важно, когда структура SCADA сети имеет распределенную архитектуру. Не подключайте системные службы или сервисы в серверах SCADA если только тщательная оценка риска последствий при использования службы не показывает, что преимущества услуги значительно перевешивают потенциальные риски уязвимости. Примеры услуг для удаления из сети SCADA включают услуги электронной почты, доступа в Интернет, системы коммерческого учета электроэнергии и биллинга. Примером, для отключения является функция дистанционного обслуживания. Многочисленные безопасные конфигурации как для коммерческих, так и с открытым исходным кодом операционных систем находятся в открытом доступе. Во-вторых, необходимо тесно сотрудничать с поставщиками SCADA, чтобы определить безопасные конфигурации и координировать любые изменения в операционной системе, обеспечивающие удаление или отключение услуги, что не должно вызывать простоев, перебоев в обслуживании, или потерю поддержки.
5. Не полагайтесь на собственные протоколы для защиты вашей системы.
Некоторые SCADA используют уникальные запатентованные протоколы для связи между полевыми устройствами и серверами. Часто безопасность SCADA основана, исключительно на закрытости этих протоколов. К сожалению, закрытость протоколов дает очень мало "реальной" безопасности. Не полагайтесь на собственные протоколы или заводские конфигурации настроек защиты вашей системы. Кроме того, требуйте, чтобы производители раскрывали все недокументированные функции и специальные сервисные интерфейсы для диагностики SCADA и предоставляли надежно защищенные решения.
6. Меры по обеспечению безопасности СКАДА, должны предоставляться производителями таких систем.
Большинство старых SCADA (большинство используемых систем) не имеют гарантий в части информационной безопасности. Владельцы SCADA должны настаивать, чтобы производители (поставщики) систем реализовывали функции информационной безопасности и поставляли их в виде патчей или обновлений. Некоторые современные SCADA поставляются с уже реализованными основными функциями информационной безопасности, но они, как правило, отключены для обеспечения простоты инсталляции. Необходимо провести анализ каждого устройства SCADA для определения, где функции информационной безопасности уже присутствуют. Кроме того, заводские параметры безопасности (как например, в компьютерной сети брандмауэры) часто устанавливаются для обеспечения максимального удобства использования, но минимальные с точки зрения безопасности. Установить все функции безопасности, чтобы обеспечить максимальный уровень безопасности. Разрешить настройки ниже максимального уровня безопасности только после тщательной оценки риска последствий снижения уровня безопасности.
7. Установить жесткий контроль использования внешних каналов доступа к данным и конфигурациям SCADA
В случае существования сервисных удаленных соединений в SCADA, должна быть реализована строгая аутентификация для обеспечения безопасной связи. Модемы, беспроводные и проводные сети, используемые для связи и технического обслуживания составляют значительную уязвимость SCADA, особенно с удаленных адресов внешних сетей. Одна успешная хакерская атака, позволит злоумышленнику обойти все другие элементы управления и получить прямой доступ к SCADA ресурсам. Чтобы минимизировать риск таких атак, необходимо отключить внешний доступ и заменить его более защищенными решениями.
8. Должны быть реализованы внутренние и внешние системы обнаружения вторжений и обеспечен мониторинг инцидентов в режиме 24х7
Чтобы быть в состоянии эффективно реагировать на кибератаки, необходимо реализовать стратегию обнаружения вторжений, которая включает в себя оповещения администраторов сети о вредоносной сетевой активности, происходящей из внутренних или внешних источников. Система обнаружения должна выполнять мониторинг сети SCADA 24 часа в сутки. Кроме того, должны быть разработаны процедуры реагирования на инциденты, что гарантирует эффективный ответ на любую атаку. В дополнение мониторинг сети, должен включать в себя ведение журнала событий для скорейшего выявления подозрительной активности.
9. Необходимо провести технический аудит устройств и сетей SCADA, и любых других, смежных сетей, для выявления проблем безопасности.
Технический аудит устройств и сети SCADA имеют решающее значение для эффективности текущей безопасности. На рынке много коммерческих и с открытым исходным кодом систем аудита безопасности, которые позволяют системным администраторам провести ревизию своих систем / сетей для выявления активных услуг и распространенных уязвимостей. Использование этих инструментов не решает системных проблем, но позволит устранить "пути наименьшего сопротивления", которыми злоумышленник может воспользоваться. Провести анализ выявленных уязвимостей, определить их важность, и предпринять корректирующие действия, проанализировать эту информацию с целью выявления тенденций. Кроме того, повторное тестирование систем после корректирующих мер, должны подтвердить, что факторы уязвимости фактически устранены. Проводить активное сканирование сети SCADA для выявления и устранения потенциальных проблем.
10. Проведение обследования и оценка безопасности всех удаленных узлов подключенных к сети SCADA
Любая точка подключения к сети SCADA является мишенью, особенно на автоматических или незащищенных удаленных узлах. Провести обследование и инвентаризацию всех таких точек доступа. Определить и оценить все источники информации, в том числе удаленные телефонные / компьютерные сети /волоконно-оптические кабели, которые могли бы быть использованы, а также радио и радиорелейные линии, подключенные компьютерные терминалы, беспроводные локальные сети. Безопасность сети СКАДА должна быть достаточной для обнаружения и предотвращения несанкционированного доступа. Не позволяйте "живой" сети обрастать точками доступа с удаленных, незащищенных адресов просто для удобства.
11. Создайте "Красную Команду" сети SCADA для выявления и оценки возможных сценариев атаки.
Создание "Красной Команды" – организационная мера, чтобы определить возможные сценарии нападения и оценки потенциальных уязвимостей системы. Привлекайте разных экспертов, которые могут дать представление о слабости всей сети, SCADA систем, физических систем, и систем контроля безопасности. Люди, которые работают в системе, каждый день лучше понимают уязвимости Вашей сети SCADA и к ним следует обращаться при определении возможных сценариев атаки и возможных последствий. Также убедитесь, что риски, связанный с внутренними злоумышленниками (ошибками персонала) минимизирован, учитывая, что это представляет собой одну из наибольших угроз для организации. Результаты, полученные от работы "Красной Команды" помогут в оценке рисков снижения надежности процессов управления и позволят установить соответствующие стратегии защиты.
Следующие шаги направлены на создание эффективной программы информационной безопасности сети СКАДА:
12. Необходимо четко определить роли, обязанности и полномочия для руководителей, системных администраторов и пользователей в области информационной безопасности
Персоналу, причастному к эксплуатации сети СКАДА, должны быть определены четкие логические роли и обязанности. Кроме того, ключевым сотрудникам нужно предоставить достаточно полномочий для выполнения возложенных на них обязанностей. Слишком часто, информационная безопасность, оказывается заложником инициатив конкретных специалистов, что обычно приводит к несовместимым реализациям и неэффективным решениям. Создание организационной структуры информационной безопасности, в которой определены роли и обязанности, позволит обеспечить четкую и слаженную работу в чрезвычайной ситуации.
13. Документирование архитектуры сети и выявление подсистем, обслуживающих важнейшие функции СКАДА или содержащие конфиденциальную информацию, которые требуют дополнительных уровней защиты
Разработать и документально оформить надежную архитектуру информационной безопасности в рамках процесса по созданию эффективной стратегии защиты. Очень важно, чтобы каждая организация проектировала сети передачи данных с учетом требований информационной безопасности и имела четкое понимание и контроль своей сетевой архитектуры на протяжении ее жизненного цикла. Особое значение имеет углубленное понимание функций подсистем и изменений требований к важности хранимой информации. Без этого понимания, риски не могут быть должным образом оценены, и стратегия защиты не может быть достаточной. Документирование архитектуры информационной безопасности и ее компонентов очень важно для понимания общей стратегии защиты.
14. Установить строгий, непрерывный процесс управления рисками
Глубокое понимание рисков атак на ресурсы вычислительной сети, а также уязвимостей конфиденциальной информации, имеет важное значение для эффективной программы информационной безопасности. Риски определяют техническую основу этого понимания и имеют решающее значение для разработки эффективных стратегий по уменьшению уязвимости целостности вычислительных ресурсов. Необходимо провести анализ исходных рисков на основе текущих оценок угроз для разработки стратегии защиты сети. В связи с быстрыми изменениями технологий и появлением новых угроз на ежедневной основе, необходим непрерывный процесс оценки рисков, также необходимо, чтобы стратегия защиты предусматривала постоянное тестирование изменений, чтобы убедиться, что все остается в силе.
15. Разработка стратегии защиты сети на основе принципа защиты в глубину
Одним из основополагающих принципов, который должен быть частью любой стратегии защиты сети - защита в глубину. Оборона –должна рассматриваться на ранних стадиях проектирования сети и должны стать неотъемлемой частью рассмотрения всех технических решений, связанных с сетью. Использование технического и административного контроля по смягчению угроз от выявленных рисков на всех уровнях сети. Информационная безопасность должна быть слоистой и ограничивать влияние любых инцидентов безопасности в одном слое на работоспособность других слоев . Кроме того, каждый слой должен быть защищен от других систем, в том же слое. Например, для защиты от внутренних угроз, ограничить пользователям доступ только к тем ресурсам, которые необходимы для выполнения своих должностных обязанностей.

16. Четко определить требования информационной безопасности
Организации и компании должны структурировать программы безопасности с фиксацией требований и ответственности за их невыполнение, что позволяет в будущем привлечь персонал к ответственности . Формализовать политики и процедуры. Официальная, утвержденная программа имеет важное значение для создания последовательного, основанного на стандартах подхода к информационной безопасности всей организации и исключает зависимость от отдельных инициативных служащих. Политика и процедуры должны также предусматривать информирование работников об их конкретных обязанностях по информационной безопасности и последствиях невыполнения этих обязанностей. Они также содержат рекомендации, касающиеся действий, которые должны быть выполнены во время инцидентов, связанных с информационной безопасностью. В рамках формирования политики информационной безопасности, заключаются пользовательские соглашения, а также развешиваются уведомления, предупреждения и баннеры. Устанавливаются требования к минимизации угрозы от инсайдеров.
17. Создавать эффективные процессы управления конфигурациями
Фундаментальный процесс управления, необходимый для поддержания безопасности сети, является управление конфигурациями. Управление конфигурацией должно охватывать как конфигурации оборудования, так и программного обеспечения. Изменениями в оборудовании или программном обеспечении можно легко получить новые уязвимости, которые подрывают безопасность сети. Необходимы процессы для оценки и контроля изменений для того, чтобы сеть оставалась в безопасности. Управление конфигурацией начинается с хорошо проверенных и документально безопасных исходных данных для ваших систем.

18. Проводить плановые самооценки
Надежная самодиагностика эффективности процессов, необходимых для обеспечения информационной безопасности, свидетельствует об эффективности проводимой политики безопасности в компании. Признаком зрелости организации является возможность самоидентифицировать вопросы, проводить анализ причин и принимать эффективные корректирующие действия, которые касаются как отдельных вопросов, так и системы в целом. Процессы самооценки являются частью эффективной программы информационной безопасности и включает регулярный поиск уязвимостей в автоматизированном режиме.
19. Внедрение системы резервного копирования и плана аварийного восстановления
Разработать план аварийного восстановления системы, что позволяет обеспечить быстрое восстановление в любой чрезвычайной ситуации (в том числе кибер-атаки). Резервные копии системы являются важной частью любого плана восстановления. Регулярно осуществлять тренировки плана аварийного восстановления, чтобы убедиться, что он работает и что сотрудники знакомы с ним. Вносить соответствующие изменения в планы аварийного восстановления на основе уроков, извлеченных из тренировок.
20. Организационными документами по информационной безопасности должны быть установлены ожидаемые параметры и ответственность лиц за результаты своей работы

Для эффективной реализации политики информационной безопасности требуется вовлечение в процесс первых руководителей компании. Очень важно, чтобы высшее руководство установило ожидания высокого уровня информационной безопасности и довело эту информацию своим подчиненным менеджерам по всей организации. Важно также, чтобы была выделена отдельная организационная структура для реализации программы информационной безопасности. Эта структура будет способствовать последовательной реализации и поддержки программы информационной безопасности. Очень важно для физических лиц нести ответственность за результаты своей работы, в том числе и в отношении к информационной безопасности. Сюда входят менеджеры, системные администраторы, техники и пользователи / операторы.
21. Разработать политику и проводить обучение, чтобы свести к минимуму вероятность того, что действия персонала непреднамеренно приведут к раскрытию конфиденциальной информации относительно системы SCADA проектирования, эксплуатации, безопасности или контроля.

Передача и копирование данных, относящихся к сети SCADA только по строгой, необходимости на основании утвержденного ранее порядка, и только лицам, непосредственно уполномоченным на получение такой информации. «Социальное проектирование», сбор информации о компьютере или
компьютерной сети с помощью вопросов к наивным пользователям, часто является первым шагом вредоносных атак на компьютерные сети. Чем больше информации выявлено около компьютера или компьютерной сети, тем более уязвимы компьютеры/
сети. Никогда не разглашать данные, относящиеся к сети SCADA, включая имена и контактную информацию о системе операторов / администраторов, компьютерных операционных систем, и / или физических и логических местах компьютеров и сетевых систем по телефонам или персонала, если они не будут явно уполномочены
получать такую информацию. Любые запросы о предоставлении информации со стороны неизвестных лиц должны быть отправлены в центральную сеть, Безопасное место для проверки и исполнения. Люди могут быть слабым звеном в самой защищенной сети. Проведение кампаний обучения и информирования должно уменьшить количество ошибок персонала и гарантировать сохранность информации, в частности, их паролей.
World

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

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