[Информационная безопасность] АСУшник смотрит на ИБ
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Не так давно большая армия российских специалистов в сфере автоматизации и эксплуатационный персонал промышленных объектов стали сталкиваться с немного непонятными и устрашающими людьми, которые появляются на объектах и «суют нос» туда, куда собственно не всех своих без присмотра пускают. Оказалось, что эти люди пришли внедрять информационную безопасность АСУ ТП. В данной статье я постарался изложить свой взгляд на то, что отличает ИБ АСУ ТП от ИБ ИТ, какие факторы надо учитывать при проектировании ИБ АСУ ТП и разработке сценариев реагирования на инциденты или угрозы ИБ на промышленном объекте.
Вот уже более 15 лет я работаю в небольшой, но достаточно известной в узких кругах российской компании из Новосибирска «Модульные Системы Торнадо», которая занимается разработкой и внедрением программно-технических комплексов для АСУ ТП объектов энергетики. За эти годы я занимался совершенно разными направлениями: программированием специализированных программных систем верхнего уровня для МП РЗА, наладкой систем телемеханики и АСУ ТП, участием в разработке современного промышленного компьютера и продажей комплексных проектов на многие десятки миллионов рублей. Такое разнообразие производственных задач, возможно, предопределило то, что меня заинтересовало это новое направление — ИБ АСУ ТП.
Но обо всем по порядку. Сейчас может показаться, что текущий, можно сказать лавинообразный рост рынка оборудования, ПО и услуг для решения задачи ИБ АСУ ТП обусловлен появлением угроз влияния на технологические процессы извне, что приводит также к закономерному росту нормативной базы регулятора ФСТЭК и т.д. Это мнение во многом справедливо, однако, мне кажется, что фундаментом этих процессов является неконтролируемое распространение интерфейса Ethernet как стандарта де-факто для организации промышленных сетей АСУ ТП. Почему неконтролируемое? Разве можно так утверждать? На мой взгляд, для этого есть все основания. Тема ИБ АСУ ТП появилась не так давно, и до этого любой проектировщик АСУ или подсистемы легким движением руки соединял сети энергоблока, ОРУ станции, главного щита управления и еще многих мелких и не очень систем контроля и управления. Все это делалось по заданиям заказчика в целях обеспечения большей наблюдаемости объекта и повышения качества контроля и управления.
К каким результатам привели эти благие намерения? Специалисты по обслуживанию технологических систем контроля и управления во многом потеряли представление о процессах, происходящих в этих ЛВС, и об их возможном влиянии на сохранение работоспособности технологического процесса. Можно подумать, что это следствие низкой квалификации персонала. Но во многих случаях это не справедливо. Дело в том, что масштаб информации для анализа персоналом влияет на адекватность восприятия состояния объекта управления. Объем промышленных сетей и число активных устройств на сегодня таково, что даже квалифицированный специалист не может предвидеть возможные последствия внесения изменений в настройки контроллеров АСУ ТП, сетевого оборудования, установки новых устройств или даже вывода подсистем управления в режимы ремонта или режимной наладки. И я пока не касаюсь вопросов внешних хакеров с различными задачами и средствами проникновения и воздействия.
Таким образом появление специалистов по ИБ на проходных промышленных объектов в общем то органично совпало с этим возрастающим напором промышленных сетей, под которым уже начали сгибаться спины доблестного эксплуатационного персонала. Эти рыцари файрволлов, антивирусных защит и систем обнаружения вторжения должны были подхватить знамя безопасности промышленного объекта, и обеспечить его бесперебойную работу в современных условиях с подключениями к интернету, удаленными каналами связи, MES и ERP всасывающими гигабайтами данные с АСУ ТП.
Считаю, что во многом эта задача современными разработчиками систем ИБ для АСУ ТП решается, или будет решена в основном объеме в ближайшие годы. Конечно, есть трудности, не все АСУ стойко переносят интеграцию средств ИБ в свои чувствительные архитектуры. Но это рабочие моменты. Однако, я думаю, что существует и ряд концептуальных вопросов, которые должны быть проанализированы поставщикам и интеграторам средств ИБ АСУ ТП.
Для того, чтобы понять эффективность средств обеспечения ИБ АСУ ТП, полезно рассмотреть те средства, которые обеспечивают ее целевые задачи. Основными задачами АСУ ТП в порядке приоритета являются:
1. Поддержание технологического процесса
2. При невозможности 1го сохранение технологического оборудования и жизни персонала
В случае развития технологической аварии существуют два варианта развития ситуации. Развитие аварийной ситуации может быть остановлено автоматическим действием подсистемы защит в составе ПТК АСУ ТП, либо остановкой технологического процесса дежурным персоналом с помощью аварийной панели управления. В данном случае будет реализована штатная остановка технологического процесса. Если же по каким-то причинам данные меры не позволили штатно остановить технологический процесс, может произойти развитие аварийной ситуации с непредсказуемыми последствиями. Итак, все современные АСУ ТП включают в свой состав программно-технические и простые аппаратные средства, предназначенные для автоматической или ручной безопасной остановки технологического процесса.
Теперь рассмотрим целевые задачи ИБ АСУ ТП. Компании разработчики программных и аппаратных средств ИБ АСУ ТП исторически являются разработчиками таких же решений для рынка ИТ. Но задачи ИБ ИТ и ИБ АСУ ТП идеологически разные. В части ИБ ИТ задача заключается в сохранении работоспособности всей ИТ инфраструктуры организации, включая все связи (связь с интернет, vpn до филиалов и т.д.). Можно даже сказать, что работоспособность этих связей является одним из главных приоритетов, поскольку полезный продукт многих организаций при отключении, например, связи с сетью интернет стремится к нулю. В части же ИБ АСУ ТП сегодня основная задача формулируется как:
1. Обеспечение функционирования АСУ ТП включая все связи
Обращает на себя внимание то обстоятельство, что в случае развития инцидента ИБ его исход может быть любым, вплоть до технологической аварии, и практически никак не зависит от дежурного персонала объекта. В настоящее время SOC для объектов с АСУ ТП практически не встречаются, а их появление может сдерживаться оценкой их финансовой и особенно целевой эффективности для АСУ ТП. Это означает что существующая парадигма развития ИБ АСУ ТП отличается отсутствием средств активного влияния на развитие инцидента ИБ АСУ ТП после момента успешного проникновения в ЛВС АСУ ТП.
На самом деле, на промышленном объекте мы можем декомпозировать все промышленные сети на условно изолированные сегменты, которые сами по себе обеспечивают работу технологического процесса. Таким образом, в критических ситуациях, или ситуациях с повышенным уровнем опасности по ИБ промышленного объекта, связи таких подсетей не являются ценными с точки зрения технологического процесса. И здесь есть первый диссонанс – специалисты по ИБ привыкли видеть своей целью сохранение работоспособности всей инфраструктуры организации, в то время как в части ИБ АСУ ТП они должны начать понимать, что не все связи являются ценными. Следовательно, в определенных ситуациях их можно физически отключать для минимизации или остановки распространения деструктивных процессов в сети АСУ ТП.
Приведу один пример. Всем нам известна авария на Саяно-Шушенской ГЭС. Я не буду касаться собственно этого объекта, развитие аварии достаточно хорошо описано. Одним из факторов, приведших к ней, стал перевод Саяно-Шушенской ГЭС в режим регулирования частоты в энергосистеме. Причина этого перевода заключается в том, что в помещении связи Братской ГЭС, являющейся основным регулятором частоты в энергосистеме Сибири, произошел пожар. В результате чего основной диспетчерский центр ОДУ Сибири потерял в полном объеме связь со всеми автоматизированными системами Братской ГЭС, включая автоматическую систему регулирования частоты и мощности. Таким образом, один из ключевых объектов энергетики Сибири выпал из автоматического процесса регулирования. Связь автоматизированных систем нарушилась. Как это повлияло на функционирование собственно Братской ГЭС? Да собственно почти никак. Конечно, станция больше не выполняла регулирование в автоматическом режиме, однако генераторы остались в работе, управление станцией велось по голосовым каналам связи из ОДУ Сибири, станционные системы автоматизации работали. Этот пример показывает, что даже потеря важных каналов контроля и управления может не приводить к остановке технологического процесса. Что же говорить про многочисленные, по сути, информационные связи АСУ ТП – передача данных в ERP и MES, общие щиты управления объектом, каналы удаленного доступа и т.д. Следовательно, в части обеспечения мер по ИБ АСУ ТП должен появиться новый принцип – не все связи ЛВС АСУ ТП являются ценными, такие связи должны выявляться при разработке проектов ИБ АСУ ТП, проектом необходимо предусматривать возможность физического отключения таких связей.
Второй диссонанс, который я чувствую, относится к реагированию на инциденты ИБ АСУ ТП. Мне, как человеку причастному к АСУ ТП, привычно, что при появлении какого-либо возмущения система управления своими алгоритмами компенсирует это возмущение. То есть имеет место активная реакция. А что же имеется в виду под термином «Реагирование на инцидент ИБ АСУ ТП»? В большинстве случаев на промышленном объекте данное действие подразумевает постанализ инцидента и принятие мер по корректировке защит и настроек в части ИБ и АСУ ТП для недопущения подобного случая в будущем. Один случай штатной остановки и последующего перезапуска крупного технологического узла может стоить десятки миллионов рублей, остановка технологического узла с повреждением технологического оборудования может стоить сотни миллионов рублей. И что, все атаки и проникновения происходят настолько быстро, что дежурный персонал (специалист по ИБ объекта по крайней мере сейчас дежурным персоналом не является) не может ничего предпринять? В большинстве случаев нет. Современные программные средства СОВ вместе с анализом ценности связей ЛВС АСУ ТП позволяют сформировать эффективные сценарии реагирования дежурного персонала объекта на инциденты в промышленных сетях АСУ ТП.
Отключение ненужных связей может остановить атаку, или предотвратить ее развитие на другие связанные ЛВС АСУ ТП. Конечно, в данном вопросе необходимо сформировать определенные сценарии анализа сообщений СОВ и оценки адекватности управляемости объекта в условиях инцидента, на основе которых необходимо формировать инструкции по действиям оперативного и дежурного персонала в условиях угрозы или реализации инцидента ИБ. Для реализации функции отключения ненужных связей может предусматриваться Аварийная Панель Управления ЛВС АСУ ТП, содержащая в своем составе размыкатели Ethernet.
И последний аспект в части внедрения современных систем СОВ для АСУ ТП. Мне кажется, что по крайней мере на сегодня основной опасностью для АСУ ТП является собственный персонал объекта или командированные специалисты. Причем, я считаю их опасными даже при условии что они не имеют установки на повреждение АСУ ТП или сами не знают что на их флэш накопителе есть программа для проникновения в АСУ ТП, активирующаяся автоматически. Сегодняшние реалии таковы, что перенастройка какого-нибудь терминала защит может на 10% увеличить загрузку сети в нормальном режиме функционирования техпроцесса. Это может привести к отказу ЛВС в момент перехода технологического процесса в предаварийный и аварийный режимы и возможному отказу технологических защит, повреждению оборудования. Данное обстоятельство должно подтолкнуть разработчиков СОВ к созданию средств отображения ключевых метрик технологических сетей АСУ ТП. Таких как: загрузка различных сегментов сетей (средняя на интервале, максимальная), время отклика, отображение потоков информации между разными подсетями для диагностики недостаточного сегментирования ЛВС и др. Такая информация, как мне представляется, будет востребована эксплуатационным персоналом и позволит поддерживать необходимый уровень гигиены процесса обмена технологическими данными в промышленных сетях АСУ ТП.
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Криптография] Швейцарская разведка с 1993 года знала о контроле над шифрованием в стране со стороны ЦРУ
- [Информационная безопасность, Разработка веб-сайтов, SQL] Web Security SQL Injection 2020
- [Информационная безопасность, Гаджеты, Умный дом] Mozilla составила рейтинг «жутких» для конфиденциальности устройств
- [Информационная безопасность, Биллинговые системы, Разработка под Windows] Microsoft завершила поддержку Windows Embedded Standard 7. Расширенный саппорт системы до 2023 года — за отдельную плату
- [Информационная безопасность, Учебный процесс в IT, Карьера в IT-индустрии, Инфографика] Продажа «корочек». Стоимость сертификатов в инфобезе и маршрут их получения
- [Информационная безопасность, Системное администрирование, Софт, Процессоры] Microsoft выпустила обновления для Windows 10 c исправлением микрокода Intel — патчи против уязвимости типа Platypus
- [Информационная безопасность, Исследования и прогнозы в IT] Изголодались по безопасности: 12% компаний будут создавать отдел ИБ «с нуля» — выводы пандемии
- [Информационная безопасность] Стартует The Standoff: все от борьбы с вирусами-шифровальщиками и вредоносного ML, до влияния COVID-19 на безопасность
- [Информационная безопасность, Исследования и прогнозы в IT, IT-компании] Telegram, Signal, Wickr Me: выбираем самый безопасный мессенджер и разбираемся, существует ли он
- [Информационная безопасность] В погоне за «неправильными» инцидентами, или Как мы строим Threat Hunting
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_informatsionnaja_bezopasnost (информационная безопасность), #_asu_tp (асу тп), #_zaschita_asu_tp (защита асу тп), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:19
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Не так давно большая армия российских специалистов в сфере автоматизации и эксплуатационный персонал промышленных объектов стали сталкиваться с немного непонятными и устрашающими людьми, которые появляются на объектах и «суют нос» туда, куда собственно не всех своих без присмотра пускают. Оказалось, что эти люди пришли внедрять информационную безопасность АСУ ТП. В данной статье я постарался изложить свой взгляд на то, что отличает ИБ АСУ ТП от ИБ ИТ, какие факторы надо учитывать при проектировании ИБ АСУ ТП и разработке сценариев реагирования на инциденты или угрозы ИБ на промышленном объекте.  Вот уже более 15 лет я работаю в небольшой, но достаточно известной в узких кругах российской компании из Новосибирска «Модульные Системы Торнадо», которая занимается разработкой и внедрением программно-технических комплексов для АСУ ТП объектов энергетики. За эти годы я занимался совершенно разными направлениями: программированием специализированных программных систем верхнего уровня для МП РЗА, наладкой систем телемеханики и АСУ ТП, участием в разработке современного промышленного компьютера и продажей комплексных проектов на многие десятки миллионов рублей. Такое разнообразие производственных задач, возможно, предопределило то, что меня заинтересовало это новое направление — ИБ АСУ ТП. Но обо всем по порядку. Сейчас может показаться, что текущий, можно сказать лавинообразный рост рынка оборудования, ПО и услуг для решения задачи ИБ АСУ ТП обусловлен появлением угроз влияния на технологические процессы извне, что приводит также к закономерному росту нормативной базы регулятора ФСТЭК и т.д. Это мнение во многом справедливо, однако, мне кажется, что фундаментом этих процессов является неконтролируемое распространение интерфейса Ethernet как стандарта де-факто для организации промышленных сетей АСУ ТП. Почему неконтролируемое? Разве можно так утверждать? На мой взгляд, для этого есть все основания. Тема ИБ АСУ ТП появилась не так давно, и до этого любой проектировщик АСУ или подсистемы легким движением руки соединял сети энергоблока, ОРУ станции, главного щита управления и еще многих мелких и не очень систем контроля и управления. Все это делалось по заданиям заказчика в целях обеспечения большей наблюдаемости объекта и повышения качества контроля и управления. К каким результатам привели эти благие намерения? Специалисты по обслуживанию технологических систем контроля и управления во многом потеряли представление о процессах, происходящих в этих ЛВС, и об их возможном влиянии на сохранение работоспособности технологического процесса. Можно подумать, что это следствие низкой квалификации персонала. Но во многих случаях это не справедливо. Дело в том, что масштаб информации для анализа персоналом влияет на адекватность восприятия состояния объекта управления. Объем промышленных сетей и число активных устройств на сегодня таково, что даже квалифицированный специалист не может предвидеть возможные последствия внесения изменений в настройки контроллеров АСУ ТП, сетевого оборудования, установки новых устройств или даже вывода подсистем управления в режимы ремонта или режимной наладки. И я пока не касаюсь вопросов внешних хакеров с различными задачами и средствами проникновения и воздействия. Таким образом появление специалистов по ИБ на проходных промышленных объектов в общем то органично совпало с этим возрастающим напором промышленных сетей, под которым уже начали сгибаться спины доблестного эксплуатационного персонала. Эти рыцари файрволлов, антивирусных защит и систем обнаружения вторжения должны были подхватить знамя безопасности промышленного объекта, и обеспечить его бесперебойную работу в современных условиях с подключениями к интернету, удаленными каналами связи, MES и ERP всасывающими гигабайтами данные с АСУ ТП. Считаю, что во многом эта задача современными разработчиками систем ИБ для АСУ ТП решается, или будет решена в основном объеме в ближайшие годы. Конечно, есть трудности, не все АСУ стойко переносят интеграцию средств ИБ в свои чувствительные архитектуры. Но это рабочие моменты. Однако, я думаю, что существует и ряд концептуальных вопросов, которые должны быть проанализированы поставщикам и интеграторам средств ИБ АСУ ТП. Для того, чтобы понять эффективность средств обеспечения ИБ АСУ ТП, полезно рассмотреть те средства, которые обеспечивают ее целевые задачи. Основными задачами АСУ ТП в порядке приоритета являются: 1. Поддержание технологического процесса 2. При невозможности 1го сохранение технологического оборудования и жизни персонала  В случае развития технологической аварии существуют два варианта развития ситуации. Развитие аварийной ситуации может быть остановлено автоматическим действием подсистемы защит в составе ПТК АСУ ТП, либо остановкой технологического процесса дежурным персоналом с помощью аварийной панели управления. В данном случае будет реализована штатная остановка технологического процесса. Если же по каким-то причинам данные меры не позволили штатно остановить технологический процесс, может произойти развитие аварийной ситуации с непредсказуемыми последствиями. Итак, все современные АСУ ТП включают в свой состав программно-технические и простые аппаратные средства, предназначенные для автоматической или ручной безопасной остановки технологического процесса. Теперь рассмотрим целевые задачи ИБ АСУ ТП. Компании разработчики программных и аппаратных средств ИБ АСУ ТП исторически являются разработчиками таких же решений для рынка ИТ. Но задачи ИБ ИТ и ИБ АСУ ТП идеологически разные. В части ИБ ИТ задача заключается в сохранении работоспособности всей ИТ инфраструктуры организации, включая все связи (связь с интернет, vpn до филиалов и т.д.). Можно даже сказать, что работоспособность этих связей является одним из главных приоритетов, поскольку полезный продукт многих организаций при отключении, например, связи с сетью интернет стремится к нулю. В части же ИБ АСУ ТП сегодня основная задача формулируется как: 1. Обеспечение функционирования АСУ ТП включая все связи  Обращает на себя внимание то обстоятельство, что в случае развития инцидента ИБ его исход может быть любым, вплоть до технологической аварии, и практически никак не зависит от дежурного персонала объекта. В настоящее время SOC для объектов с АСУ ТП практически не встречаются, а их появление может сдерживаться оценкой их финансовой и особенно целевой эффективности для АСУ ТП. Это означает что существующая парадигма развития ИБ АСУ ТП отличается отсутствием средств активного влияния на развитие инцидента ИБ АСУ ТП после момента успешного проникновения в ЛВС АСУ ТП. На самом деле, на промышленном объекте мы можем декомпозировать все промышленные сети на условно изолированные сегменты, которые сами по себе обеспечивают работу технологического процесса. Таким образом, в критических ситуациях, или ситуациях с повышенным уровнем опасности по ИБ промышленного объекта, связи таких подсетей не являются ценными с точки зрения технологического процесса. И здесь есть первый диссонанс – специалисты по ИБ привыкли видеть своей целью сохранение работоспособности всей инфраструктуры организации, в то время как в части ИБ АСУ ТП они должны начать понимать, что не все связи являются ценными. Следовательно, в определенных ситуациях их можно физически отключать для минимизации или остановки распространения деструктивных процессов в сети АСУ ТП. Приведу один пример. Всем нам известна авария на Саяно-Шушенской ГЭС. Я не буду касаться собственно этого объекта, развитие аварии достаточно хорошо описано. Одним из факторов, приведших к ней, стал перевод Саяно-Шушенской ГЭС в режим регулирования частоты в энергосистеме. Причина этого перевода заключается в том, что в помещении связи Братской ГЭС, являющейся основным регулятором частоты в энергосистеме Сибири, произошел пожар. В результате чего основной диспетчерский центр ОДУ Сибири потерял в полном объеме связь со всеми автоматизированными системами Братской ГЭС, включая автоматическую систему регулирования частоты и мощности. Таким образом, один из ключевых объектов энергетики Сибири выпал из автоматического процесса регулирования. Связь автоматизированных систем нарушилась. Как это повлияло на функционирование собственно Братской ГЭС? Да собственно почти никак. Конечно, станция больше не выполняла регулирование в автоматическом режиме, однако генераторы остались в работе, управление станцией велось по голосовым каналам связи из ОДУ Сибири, станционные системы автоматизации работали. Этот пример показывает, что даже потеря важных каналов контроля и управления может не приводить к остановке технологического процесса. Что же говорить про многочисленные, по сути, информационные связи АСУ ТП – передача данных в ERP и MES, общие щиты управления объектом, каналы удаленного доступа и т.д. Следовательно, в части обеспечения мер по ИБ АСУ ТП должен появиться новый принцип – не все связи ЛВС АСУ ТП являются ценными, такие связи должны выявляться при разработке проектов ИБ АСУ ТП, проектом необходимо предусматривать возможность физического отключения таких связей. Второй диссонанс, который я чувствую, относится к реагированию на инциденты ИБ АСУ ТП. Мне, как человеку причастному к АСУ ТП, привычно, что при появлении какого-либо возмущения система управления своими алгоритмами компенсирует это возмущение. То есть имеет место активная реакция. А что же имеется в виду под термином «Реагирование на инцидент ИБ АСУ ТП»? В большинстве случаев на промышленном объекте данное действие подразумевает постанализ инцидента и принятие мер по корректировке защит и настроек в части ИБ и АСУ ТП для недопущения подобного случая в будущем. Один случай штатной остановки и последующего перезапуска крупного технологического узла может стоить десятки миллионов рублей, остановка технологического узла с повреждением технологического оборудования может стоить сотни миллионов рублей. И что, все атаки и проникновения происходят настолько быстро, что дежурный персонал (специалист по ИБ объекта по крайней мере сейчас дежурным персоналом не является) не может ничего предпринять? В большинстве случаев нет. Современные программные средства СОВ вместе с анализом ценности связей ЛВС АСУ ТП позволяют сформировать эффективные сценарии реагирования дежурного персонала объекта на инциденты в промышленных сетях АСУ ТП.  Отключение ненужных связей может остановить атаку, или предотвратить ее развитие на другие связанные ЛВС АСУ ТП. Конечно, в данном вопросе необходимо сформировать определенные сценарии анализа сообщений СОВ и оценки адекватности управляемости объекта в условиях инцидента, на основе которых необходимо формировать инструкции по действиям оперативного и дежурного персонала в условиях угрозы или реализации инцидента ИБ. Для реализации функции отключения ненужных связей может предусматриваться Аварийная Панель Управления ЛВС АСУ ТП, содержащая в своем составе размыкатели Ethernet. И последний аспект в части внедрения современных систем СОВ для АСУ ТП. Мне кажется, что по крайней мере на сегодня основной опасностью для АСУ ТП является собственный персонал объекта или командированные специалисты. Причем, я считаю их опасными даже при условии что они не имеют установки на повреждение АСУ ТП или сами не знают что на их флэш накопителе есть программа для проникновения в АСУ ТП, активирующаяся автоматически. Сегодняшние реалии таковы, что перенастройка какого-нибудь терминала защит может на 10% увеличить загрузку сети в нормальном режиме функционирования техпроцесса. Это может привести к отказу ЛВС в момент перехода технологического процесса в предаварийный и аварийный режимы и возможному отказу технологических защит, повреждению оборудования. Данное обстоятельство должно подтолкнуть разработчиков СОВ к созданию средств отображения ключевых метрик технологических сетей АСУ ТП. Таких как: загрузка различных сегментов сетей (средняя на интервале, максимальная), время отклика, отображение потоков информации между разными подсетями для диагностики недостаточного сегментирования ЛВС и др. Такая информация, как мне представляется, будет востребована эксплуатационным персоналом и позволит поддерживать необходимый уровень гигиены процесса обмена технологическими данными в промышленных сетях АСУ ТП. =========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:19
Часовой пояс: UTC + 5