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