Не так давно большая армия российских специалистов в сфере автоматизации и эксплуатационный персонал промышленных объектов стали сталкиваться с немного непонятными и устрашающими людьми, которые появляются на объектах и «суют нос» туда, куда собственно не всех своих без присмотра пускают. Оказалось, что эти люди пришли внедрять информационную безопасность АСУ ТП. В данной статье я постарался изложить свой взгляд на то, что отличает ИБ АСУ ТП от ИБ ИТ, какие факторы надо учитывать при проектировании ИБ АСУ ТП и разработке сценариев реагирования на инциденты или угрозы ИБ на промышленном объекте.
Вот уже более 15 лет я работаю в небольшой, но достаточно известной в узких кругах российской компании из Новосибирска «Модульные Системы Торнадо», которая занимается разработкой и внедрением программно-технических комплексов для АСУ ТП объектов энергетики. За эти годы я занимался совершенно разными направлениями: программированием специализированных программных систем верхнего уровня для МП РЗА, наладкой систем телемеханики и АСУ ТП, участием в разработке современного промышленного компьютера и продажей комплексных проектов на многие десятки миллионов рублей. Такое разнообразие производственных задач, возможно, предопределило то, что меня заинтересовало это новое направление — ИБ АСУ ТП.
Но обо всем по порядку. Сейчас может показаться, что текущий, можно сказать лавинообразный рост рынка оборудования, ПО и услуг для решения задачи ИБ АСУ ТП обусловлен появлением угроз влияния на технологические процессы извне, что приводит также к закономерному росту нормативной базы регулятора ФСТЭК и т.д. Это мнение во многом справедливо, однако, мне кажется, что фундаментом этих процессов является неконтролируемое распространение интерфейса Ethernet как стандарта де-факто для организации промышленных сетей АСУ ТП. Почему неконтролируемое? Разве можно так утверждать? На мой взгляд, для этого есть все основания. Тема ИБ АСУ ТП появилась не так давно, и до этого любой проектировщик АСУ или подсистемы легким движением руки соединял сети энергоблока, ОРУ станции, главного щита управления и еще многих мелких и не очень систем контроля и управления. Все это делалось по заданиям заказчика в целях обеспечения большей наблюдаемости объекта и повышения качества контроля и управления.
К каким результатам привели эти благие намерения? Специалисты по обслуживанию технологических систем контроля и управления во многом потеряли представление о процессах, происходящих в этих ЛВС, и об их возможном влиянии на сохранение работоспособности технологического процесса. Можно подумать, что это следствие низкой квалификации персонала. Но во многих случаях это не справедливо. Дело в том, что масштаб информации для анализа персоналом влияет на адекватность восприятия состояния объекта управления. Объем промышленных сетей и число активных устройств на сегодня таково, что даже квалифицированный специалист не может предвидеть возможные последствия внесения изменений в настройки контроллеров АСУ ТП, сетевого оборудования, установки новых устройств или даже вывода подсистем управления в режимы ремонта или режимной наладки. И я пока не касаюсь вопросов внешних хакеров с различными задачами и средствами проникновения и воздействия.
Таким образом появление специалистов по ИБ на проходных промышленных объектов в общем то органично совпало с этим возрастающим напором промышленных сетей, под которым уже начали сгибаться спины доблестного эксплуатационного персонала. Эти рыцари файрволлов, антивирусных защит и систем обнаружения вторжения должны были подхватить знамя безопасности промышленного объекта, и обеспечить его бесперебойную работу в современных условиях с подключениями к интернету, удаленными каналами связи, MES и ERP всасывающими гигабайтами данные с АСУ ТП.
Считаю, что во многом эта задача современными разработчиками систем ИБ для АСУ ТП решается, или будет решена в основном объеме в ближайшие годы. Конечно, есть трудности, не все АСУ стойко переносят интеграцию средств ИБ в свои чувствительные архитектуры. Но это рабочие моменты. Однако, я думаю, что существует и ряд концептуальных вопросов, которые должны быть проанализированы поставщикам и интеграторам средств ИБ АСУ ТП.
Для того, чтобы понять эффективность средств обеспечения ИБ АСУ ТП, полезно рассмотреть те средства, которые обеспечивают ее целевые задачи. Основными задачами АСУ ТП в порядке приоритета являются:
1. Поддержание технологического процесса
2. При невозможности 1го сохранение технологического оборудования и жизни персонала
В случае развития технологической аварии существуют два варианта развития ситуации. Развитие аварийной ситуации может быть остановлено автоматическим действием подсистемы защит в составе ПТК АСУ ТП, либо остановкой технологического процесса дежурным персоналом с помощью аварийной панели управления. В данном случае будет реализована штатная остановка технологического процесса. Если же по каким-то причинам данные меры не позволили штатно остановить технологический процесс, может произойти развитие аварийной ситуации с непредсказуемыми последствиями. Итак, все современные АСУ ТП включают в свой состав программно-технические и простые аппаратные средства, предназначенные для автоматической или ручной безопасной остановки технологического процесса.
Теперь рассмотрим целевые задачи ИБ АСУ ТП. Компании разработчики программных и аппаратных средств ИБ АСУ ТП исторически являются разработчиками таких же решений для рынка ИТ. Но задачи ИБ ИТ и ИБ АСУ ТП идеологически разные. В части ИБ ИТ задача заключается в сохранении работоспособности всей ИТ инфраструктуры организации, включая все связи (связь с интернет, vpn до филиалов и т.д.). Можно даже сказать, что работоспособность этих связей является одним из главных приоритетов, поскольку полезный продукт многих организаций при отключении, например, связи с сетью интернет стремится к нулю. В части же ИБ АСУ ТП сегодня основная задача формулируется как:
1. Обеспечение функционирования АСУ ТП включая все связи
Обращает на себя внимание то обстоятельство, что в случае развития инцидента ИБ его исход может быть любым, вплоть до технологической аварии, и практически никак не зависит от дежурного персонала объекта. В настоящее время SOC для объектов с АСУ ТП практически не встречаются, а их появление может сдерживаться оценкой их финансовой и особенно целевой эффективности для АСУ ТП. Это означает что существующая парадигма развития ИБ АСУ ТП отличается отсутствием средств активного влияния на развитие инцидента ИБ АСУ ТП после момента успешного проникновения в ЛВС АСУ ТП.
На самом деле, на промышленном объекте мы можем декомпозировать все промышленные сети на условно изолированные сегменты, которые сами по себе обеспечивают работу технологического процесса. Таким образом, в критических ситуациях, или ситуациях с повышенным уровнем опасности по ИБ промышленного объекта, связи таких подсетей не являются ценными с точки зрения технологического процесса. И здесь есть первый диссонанс – специалисты по ИБ привыкли видеть своей целью сохранение работоспособности всей инфраструктуры организации, в то время как в части ИБ АСУ ТП они должны начать понимать, что не все связи являются ценными. Следовательно, в определенных ситуациях их можно физически отключать для минимизации или остановки распространения деструктивных процессов в сети АСУ ТП.
Приведу один пример. Всем нам известна авария на Саяно-Шушенской ГЭС. Я не буду касаться собственно этого объекта, развитие аварии достаточно хорошо описано. Одним из факторов, приведших к ней, стал перевод Саяно-Шушенской ГЭС в режим регулирования частоты в энергосистеме. Причина этого перевода заключается в том, что в помещении связи Братской ГЭС, являющейся основным регулятором частоты в энергосистеме Сибири, произошел пожар. В результате чего основной диспетчерский центр ОДУ Сибири потерял в полном объеме связь со всеми автоматизированными системами Братской ГЭС, включая автоматическую систему регулирования частоты и мощности. Таким образом, один из ключевых объектов энергетики Сибири выпал из автоматического процесса регулирования. Связь автоматизированных систем нарушилась. Как это повлияло на функционирование собственно Братской ГЭС? Да собственно почти никак. Конечно, станция больше не выполняла регулирование в автоматическом режиме, однако генераторы остались в работе, управление станцией велось по голосовым каналам связи из ОДУ Сибири, станционные системы автоматизации работали. Этот пример показывает, что даже потеря важных каналов контроля и управления может не приводить к остановке технологического процесса. Что же говорить про многочисленные, по сути, информационные связи АСУ ТП – передача данных в ERP и MES, общие щиты управления объектом, каналы удаленного доступа и т.д. Следовательно, в части обеспечения мер по ИБ АСУ ТП должен появиться новый принцип – не все связи ЛВС АСУ ТП являются ценными, такие связи должны выявляться при разработке проектов ИБ АСУ ТП, проектом необходимо предусматривать возможность физического отключения таких связей.
Второй диссонанс, который я чувствую, относится к реагированию на инциденты ИБ АСУ ТП. Мне, как человеку причастному к АСУ ТП, привычно, что при появлении какого-либо возмущения система управления своими алгоритмами компенсирует это возмущение. То есть имеет место активная реакция. А что же имеется в виду под термином «Реагирование на инцидент ИБ АСУ ТП»? В большинстве случаев на промышленном объекте данное действие подразумевает постанализ инцидента и принятие мер по корректировке защит и настроек в части ИБ и АСУ ТП для недопущения подобного случая в будущем. Один случай штатной остановки и последующего перезапуска крупного технологического узла может стоить десятки миллионов рублей, остановка технологического узла с повреждением технологического оборудования может стоить сотни миллионов рублей. И что, все атаки и проникновения происходят настолько быстро, что дежурный персонал (специалист по ИБ объекта по крайней мере сейчас дежурным персоналом не является) не может ничего предпринять? В большинстве случаев нет. Современные программные средства СОВ вместе с анализом ценности связей ЛВС АСУ ТП позволяют сформировать эффективные сценарии реагирования дежурного персонала объекта на инциденты в промышленных сетях АСУ ТП.
Отключение ненужных связей может остановить атаку, или предотвратить ее развитие на другие связанные ЛВС АСУ ТП. Конечно, в данном вопросе необходимо сформировать определенные сценарии анализа сообщений СОВ и оценки адекватности управляемости объекта в условиях инцидента, на основе которых необходимо формировать инструкции по действиям оперативного и дежурного персонала в условиях угрозы или реализации инцидента ИБ. Для реализации функции отключения ненужных связей может предусматриваться Аварийная Панель Управления ЛВС АСУ ТП, содержащая в своем составе размыкатели Ethernet.
И последний аспект в части внедрения современных систем СОВ для АСУ ТП. Мне кажется, что по крайней мере на сегодня основной опасностью для АСУ ТП является собственный персонал объекта или командированные специалисты. Причем, я считаю их опасными даже при условии что они не имеют установки на повреждение АСУ ТП или сами не знают что на их флэш накопителе есть программа для проникновения в АСУ ТП, активирующаяся автоматически. Сегодняшние реалии таковы, что перенастройка какого-нибудь терминала защит может на 10% увеличить загрузку сети в нормальном режиме функционирования техпроцесса. Это может привести к отказу ЛВС в момент перехода технологического процесса в предаварийный и аварийный режимы и возможному отказу технологических защит, повреждению оборудования. Данное обстоятельство должно подтолкнуть разработчиков СОВ к созданию средств отображения ключевых метрик технологических сетей АСУ ТП. Таких как: загрузка различных сегментов сетей (средняя на интервале, максимальная), время отклика, отображение потоков информации между разными подсетями для диагностики недостаточного сегментирования ЛВС и др. Такая информация, как мне представляется, будет востребована эксплуатационным персоналом и позволит поддерживать необходимый уровень гигиены процесса обмена технологическими данными в промышленных сетях АСУ ТП.
Вот уже более 15 лет я работаю в небольшой, но достаточно известной в узких кругах российской компании из Новосибирска «Модульные Системы Торнадо», которая занимается разработкой и внедрением программно-технических комплексов для АСУ ТП объектов энергетики. За эти годы я занимался совершенно разными направлениями: программированием специализированных программных систем верхнего уровня для МП РЗА, наладкой систем телемеханики и АСУ ТП, участием в разработке современного промышленного компьютера и продажей комплексных проектов на многие десятки миллионов рублей. Такое разнообразие производственных задач, возможно, предопределило то, что меня заинтересовало это новое направление — ИБ АСУ ТП.
Но обо всем по порядку. Сейчас может показаться, что текущий, можно сказать лавинообразный рост рынка оборудования, ПО и услуг для решения задачи ИБ АСУ ТП обусловлен появлением угроз влияния на технологические процессы извне, что приводит также к закономерному росту нормативной базы регулятора ФСТЭК и т.д. Это мнение во многом справедливо, однако, мне кажется, что фундаментом этих процессов является неконтролируемое распространение интерфейса Ethernet как стандарта де-факто для организации промышленных сетей АСУ ТП. Почему неконтролируемое? Разве можно так утверждать? На мой взгляд, для этого есть все основания. Тема ИБ АСУ ТП появилась не так давно, и до этого любой проектировщик АСУ или подсистемы легким движением руки соединял сети энергоблока, ОРУ станции, главного щита управления и еще многих мелких и не очень систем контроля и управления. Все это делалось по заданиям заказчика в целях обеспечения большей наблюдаемости объекта и повышения качества контроля и управления.
К каким результатам привели эти благие намерения? Специалисты по обслуживанию технологических систем контроля и управления во многом потеряли представление о процессах, происходящих в этих ЛВС, и об их возможном влиянии на сохранение работоспособности технологического процесса. Можно подумать, что это следствие низкой квалификации персонала. Но во многих случаях это не справедливо. Дело в том, что масштаб информации для анализа персоналом влияет на адекватность восприятия состояния объекта управления. Объем промышленных сетей и число активных устройств на сегодня таково, что даже квалифицированный специалист не может предвидеть возможные последствия внесения изменений в настройки контроллеров АСУ ТП, сетевого оборудования, установки новых устройств или даже вывода подсистем управления в режимы ремонта или режимной наладки. И я пока не касаюсь вопросов внешних хакеров с различными задачами и средствами проникновения и воздействия.
Таким образом появление специалистов по ИБ на проходных промышленных объектов в общем то органично совпало с этим возрастающим напором промышленных сетей, под которым уже начали сгибаться спины доблестного эксплуатационного персонала. Эти рыцари файрволлов, антивирусных защит и систем обнаружения вторжения должны были подхватить знамя безопасности промышленного объекта, и обеспечить его бесперебойную работу в современных условиях с подключениями к интернету, удаленными каналами связи, MES и ERP всасывающими гигабайтами данные с АСУ ТП.
Считаю, что во многом эта задача современными разработчиками систем ИБ для АСУ ТП решается, или будет решена в основном объеме в ближайшие годы. Конечно, есть трудности, не все АСУ стойко переносят интеграцию средств ИБ в свои чувствительные архитектуры. Но это рабочие моменты. Однако, я думаю, что существует и ряд концептуальных вопросов, которые должны быть проанализированы поставщикам и интеграторам средств ИБ АСУ ТП.
Для того, чтобы понять эффективность средств обеспечения ИБ АСУ ТП, полезно рассмотреть те средства, которые обеспечивают ее целевые задачи. Основными задачами АСУ ТП в порядке приоритета являются:
1. Поддержание технологического процесса
2. При невозможности 1го сохранение технологического оборудования и жизни персонала
В случае развития технологической аварии существуют два варианта развития ситуации. Развитие аварийной ситуации может быть остановлено автоматическим действием подсистемы защит в составе ПТК АСУ ТП, либо остановкой технологического процесса дежурным персоналом с помощью аварийной панели управления. В данном случае будет реализована штатная остановка технологического процесса. Если же по каким-то причинам данные меры не позволили штатно остановить технологический процесс, может произойти развитие аварийной ситуации с непредсказуемыми последствиями. Итак, все современные АСУ ТП включают в свой состав программно-технические и простые аппаратные средства, предназначенные для автоматической или ручной безопасной остановки технологического процесса.
Теперь рассмотрим целевые задачи ИБ АСУ ТП. Компании разработчики программных и аппаратных средств ИБ АСУ ТП исторически являются разработчиками таких же решений для рынка ИТ. Но задачи ИБ ИТ и ИБ АСУ ТП идеологически разные. В части ИБ ИТ задача заключается в сохранении работоспособности всей ИТ инфраструктуры организации, включая все связи (связь с интернет, vpn до филиалов и т.д.). Можно даже сказать, что работоспособность этих связей является одним из главных приоритетов, поскольку полезный продукт многих организаций при отключении, например, связи с сетью интернет стремится к нулю. В части же ИБ АСУ ТП сегодня основная задача формулируется как:
1. Обеспечение функционирования АСУ ТП включая все связи
Обращает на себя внимание то обстоятельство, что в случае развития инцидента ИБ его исход может быть любым, вплоть до технологической аварии, и практически никак не зависит от дежурного персонала объекта. В настоящее время SOC для объектов с АСУ ТП практически не встречаются, а их появление может сдерживаться оценкой их финансовой и особенно целевой эффективности для АСУ ТП. Это означает что существующая парадигма развития ИБ АСУ ТП отличается отсутствием средств активного влияния на развитие инцидента ИБ АСУ ТП после момента успешного проникновения в ЛВС АСУ ТП.
На самом деле, на промышленном объекте мы можем декомпозировать все промышленные сети на условно изолированные сегменты, которые сами по себе обеспечивают работу технологического процесса. Таким образом, в критических ситуациях, или ситуациях с повышенным уровнем опасности по ИБ промышленного объекта, связи таких подсетей не являются ценными с точки зрения технологического процесса. И здесь есть первый диссонанс – специалисты по ИБ привыкли видеть своей целью сохранение работоспособности всей инфраструктуры организации, в то время как в части ИБ АСУ ТП они должны начать понимать, что не все связи являются ценными. Следовательно, в определенных ситуациях их можно физически отключать для минимизации или остановки распространения деструктивных процессов в сети АСУ ТП.
Приведу один пример. Всем нам известна авария на Саяно-Шушенской ГЭС. Я не буду касаться собственно этого объекта, развитие аварии достаточно хорошо описано. Одним из факторов, приведших к ней, стал перевод Саяно-Шушенской ГЭС в режим регулирования частоты в энергосистеме. Причина этого перевода заключается в том, что в помещении связи Братской ГЭС, являющейся основным регулятором частоты в энергосистеме Сибири, произошел пожар. В результате чего основной диспетчерский центр ОДУ Сибири потерял в полном объеме связь со всеми автоматизированными системами Братской ГЭС, включая автоматическую систему регулирования частоты и мощности. Таким образом, один из ключевых объектов энергетики Сибири выпал из автоматического процесса регулирования. Связь автоматизированных систем нарушилась. Как это повлияло на функционирование собственно Братской ГЭС? Да собственно почти никак. Конечно, станция больше не выполняла регулирование в автоматическом режиме, однако генераторы остались в работе, управление станцией велось по голосовым каналам связи из ОДУ Сибири, станционные системы автоматизации работали. Этот пример показывает, что даже потеря важных каналов контроля и управления может не приводить к остановке технологического процесса. Что же говорить про многочисленные, по сути, информационные связи АСУ ТП – передача данных в ERP и MES, общие щиты управления объектом, каналы удаленного доступа и т.д. Следовательно, в части обеспечения мер по ИБ АСУ ТП должен появиться новый принцип – не все связи ЛВС АСУ ТП являются ценными, такие связи должны выявляться при разработке проектов ИБ АСУ ТП, проектом необходимо предусматривать возможность физического отключения таких связей.
Второй диссонанс, который я чувствую, относится к реагированию на инциденты ИБ АСУ ТП. Мне, как человеку причастному к АСУ ТП, привычно, что при появлении какого-либо возмущения система управления своими алгоритмами компенсирует это возмущение. То есть имеет место активная реакция. А что же имеется в виду под термином «Реагирование на инцидент ИБ АСУ ТП»? В большинстве случаев на промышленном объекте данное действие подразумевает постанализ инцидента и принятие мер по корректировке защит и настроек в части ИБ и АСУ ТП для недопущения подобного случая в будущем. Один случай штатной остановки и последующего перезапуска крупного технологического узла может стоить десятки миллионов рублей, остановка технологического узла с повреждением технологического оборудования может стоить сотни миллионов рублей. И что, все атаки и проникновения происходят настолько быстро, что дежурный персонал (специалист по ИБ объекта по крайней мере сейчас дежурным персоналом не является) не может ничего предпринять? В большинстве случаев нет. Современные программные средства СОВ вместе с анализом ценности связей ЛВС АСУ ТП позволяют сформировать эффективные сценарии реагирования дежурного персонала объекта на инциденты в промышленных сетях АСУ ТП.
Отключение ненужных связей может остановить атаку, или предотвратить ее развитие на другие связанные ЛВС АСУ ТП. Конечно, в данном вопросе необходимо сформировать определенные сценарии анализа сообщений СОВ и оценки адекватности управляемости объекта в условиях инцидента, на основе которых необходимо формировать инструкции по действиям оперативного и дежурного персонала в условиях угрозы или реализации инцидента ИБ. Для реализации функции отключения ненужных связей может предусматриваться Аварийная Панель Управления ЛВС АСУ ТП, содержащая в своем составе размыкатели Ethernet.
И последний аспект в части внедрения современных систем СОВ для АСУ ТП. Мне кажется, что по крайней мере на сегодня основной опасностью для АСУ ТП является собственный персонал объекта или командированные специалисты. Причем, я считаю их опасными даже при условии что они не имеют установки на повреждение АСУ ТП или сами не знают что на их флэш накопителе есть программа для проникновения в АСУ ТП, активирующаяся автоматически. Сегодняшние реалии таковы, что перенастройка какого-нибудь терминала защит может на 10% увеличить загрузку сети в нормальном режиме функционирования техпроцесса. Это может привести к отказу ЛВС в момент перехода технологического процесса в предаварийный и аварийный режимы и возможному отказу технологических защит, повреждению оборудования. Данное обстоятельство должно подтолкнуть разработчиков СОВ к созданию средств отображения ключевых метрик технологических сетей АСУ ТП. Таких как: загрузка различных сегментов сетей (средняя на интервале, максимальная), время отклика, отображение потоков информации между разными подсетями для диагностики недостаточного сегментирования ЛВС и др. Такая информация, как мне представляется, будет востребована эксплуатационным персоналом и позволит поддерживать необходимый уровень гигиены процесса обмена технологическими данными в промышленных сетях АСУ ТП.
lelik363
Вам не кажется, что в такой формулировке кроется противоречие?
etherCUT Автор
Пример конечно немного провакационный. Но если не рассматривать варианты одновременной атаки на энергосистему в целом, можно увидеть что отключение информационных связей одного объекта не повлияет сильно на управляемость скажем энергосистемы. Параметры такого «изолрованного» объекта для внешнего центра управления можно понять по параметрам окружающих объектов. Это справедливо и для электроэнергетики, транспортировки нефти и газа. В случае атаки на объект вопрос эффективности технологического режима вторичен по отношении к вопросу поддержания технологического процесса. Если бы на СШ ГЭС не случилось то, что случилось, в энергосистеме не было бы отключений крупных и мелких потребителей.
AnatolPe
А это отключение причем тут АСУ? Это отдельный раздел ПА(противоаварийная автоматика) Это целый раздел который «курят» Противоаварийщики, минимально что видит специалист на уровне МРСК шкаф АЧР/АОСН… Повлиять на него можно, но это на низком уровне… МКПА и реализованные на них алгоритмы- вот там да повлиять можно, но внешние связи это УПАСК- передача сугубо дискретных команд через весьма специфическую сеть… Да как то мы разыгрались и разгрузили Маяковскую ТЭС на все ее тестовые в те момент 75МВт, но это сугубо баловство путем замыкания контактов проводом…
Проблема АСУ-ТП в энергетике и не только в ней, это полное непонимание персонала Пусконаладочных контор, и производителей, как оно должно работать с учетом работы ИБ… Там принцип простой «Мы говорим вот так оно будет работать, а слову джентльмена надо верить неприкосновно»
Даже тот же Siemens, ABB, Sprecon, Mikronika, (специально не пишу про наши комплексы) делает такие фортели в своих терминалах, в своем ПО… Что говорить про оборудование Moxa, Etherwan, Hirschmann, Ruggedcom Оборудование которое предназначено для Подстанций, а глючит так что… Не говоря про то что если его настроить по требованиям ИБ, оно не будет работать нормально от слова вообще… И поэтому внедряя системы Фаерволы и системы мониторинга вторжения в сеть АСУ-ТП надо прекрасно понимать уже особенности работы оборудования и тонкости каждого подразделения МРСК… Надо понимать что Человеческий фактор самое главное в ИБ, а когда сеть АСУ и сеть-шина процесса, шина станции, сливается в единое, где релейщики которые знают что такое «Ток» но не знают что такое mac адрес, рулят работой… А АСУшник/СДТУшник не знает что такое ИБ… А ИБ специалист вообще не знает обе предыдущие специальности и особенности то получаем такие интересные объекты… Одно радует в России в отличии от той же Польши и Германии сети ПС в 90% изолированны от общей сети Интернет… В Польше например без проблем можно зайти на Ветряки по одному IP адресу(при этом есть нат/пат и куча портов открытых-Web морд контроллеров ветропарков — 60шт :) ) и ПС Эльблонг с WEB мордой сименса и Windows серевером 2003, без патчей и включенным RDP, долго красовалось в интернете, может быть и сейчас красуется, но как то вдоволь поигравшись забил на это… :)