Intro
Так сложилось, что создание основной массы автоматизированных систем управления технологическим процессом (АСУ ТП) в нашей стране пришлось на конец XX века. И тогда ресурса, заложенного для полноценного функционирования и дальнейшего масштабирования, было вполне достаточно. То есть проблемы, с которыми мы сталкиваемся при проектировании систем обеспечения информационной безопасности (СОИБ), пришли со временем и являются результатом влияния изменений законодательства, морального устаревания оборудования, увеличения компетенций персонала и роста уровня цифровизации.
Исходя из опыта последних реализованных проектов и текущих работ, мы выявили 7 «кругов» проблем, которые в данной статье постараемся закрыть.
1 Невозможность использования морально устаревших продуктов
Проблема:
Верхний уровень визуализации, мониторинга и сбора данных разрабатывался на актуальных для своего времени операционных системах. Но сегодня, с учетом текущей геополитической ситуации и всеобщим импортозамещением, это влечет за собой сразу несколько проблем:
Прикладное программное обеспечение (ППО) для ранее спроектированного АСУ ТП может функционировать только под Windows, начиная с XP. В таком случае возможности ОС ограничены, используются минимально допустимые программно-аппаратные требования, а заложенный резерв давно иссяк.
АСУ ТП, которые на данный момент модернизируются или разрабатываются с нуля, «спотыкаются» об невозможность или нежелание вендора разрабатывать ППО верхнего уровня на базе доступных отечественных ОС. Нередки ситуации, когда верхний уровень функционирует на Linux, в то время как средний уровень программируемых логических контроллеров приходится обновлять с рабочей станции под ОС Windows.
Иностранные вендоры, ушедшие с рынка, не оставили документации — и пользователи лишились поддержки. Ранее сервисные организации обслуживали оборудование полностью, теперь либо штатные сотрудники самостоятельно разбираются в возникающих проблемах, либо организациям приходится искать решение на аутсорсе.
У сертифицированных, казалось бы, средств защиты информации (СрЗИ) как единственная доступная для развертывания ОС указана Windows, а в списке рекомендуемых систем виртуализации и СУБД часто не встретишь ни одной отечественной.
Результат:
С одной стороны, к изменениям подталкивают законодательные требования, направленные на импортозамещение (при этом отечественный рынок решений не готов удовлетворять все запросы). С другой стороны, ранее внедренные решения потеряли часть функционала и поддержку, что также заставляет задуматься о переходе. А с третьей — к нам стучится «окно возможностей» и пожелания бизнеса по учету тенденций и модернизаций устаревшей инфраструктуры.
Решение:
Использование наложенных средств защиты (средств от НСД либо наложенных средств защиты виртуальной среды) там, где невозможно использовать встроенный функционал. При этом требуется помнить о том «за какую команду мы играем». Безопасность должна быть не просто безопасной, а ещё и адекватной. В случае, если резервных ресурсов для использования дополнительного ПО недостаточно, мы не должны подвергать риску работоспособность существующей системы, основной технологический процесс. Тогда мы усиливаем меры физической, промышленной и иной безопасности: доступы в помещения, ведение журналов, средства сетевой безопасности, непрерывный харденинг и использование средств мониторинга. Мы анализируем трафик промышленной сети для выявления отклонений и также учитываем требования к масштабированию в грядущей модернизации.
2 Неготовность инфраструктуры
Проблема:
За годы, прошедшие с ввода АСУ ТП в эксплуатацию, скорее всего, было проведено огромное количество модернизаций и смежных проектов с разными целями и бюджетами. В результате на объекте, спустя 10 лет, мы имеем разнородную инфраструктуру и невероятный «зоопарк» программно-аппаратного обеспечения.
В таком случае мы получаем исходные данные, согласно которым пропускная способность каналов связи недостаточна, резерв питания исчерпан, зато в избытке проблемы с кондиционированием и свободным местом для расположения нового оборудования.
Результат:
Отсутствует упорядоченность IT-активов, часть оборудования не учтена, некорректно организована сетевая инфраструктура, плоская IP-адресация, смешение корпоративной и технологической сети, структурные схемы и формуляры на оборудование отсутствуют.
Нет понимания, как выглядит и из чего состоит изначальная инфраструктура. А те исходные данные, которые «потом и кровью» все же удается добыть, не соответствуют предъявляемым в нашем десятилетии требованиям — что затрудняет интеграцию вновь проектируемых технологических решений или средств безопасности.
Решение:
В идеальном мире перед внедрением СОИБ следует привести в порядок имеющуюся инфраструктуру, составить дорожную карту по модернизации сети и устройств, если того требует ситуация, а также разработать план мероприятий по импортозамещению. Срок службы АСУ ТП — 5-10 лет с дальнейшим продлением срока эксплуатации. Таким образом, при модернизации требуется учитывать масштабирование системы с избытком, с прицелом на будущее.
3 Ограниченный функционал отечественных решений
Проблема:
В свете столкновения с проблемой импортозамещения в целом, в частных случаях появляются замечания к несоответствию маркетинговых заявлений вендора действительности. Особенно остро это заметно в области решений сетевой безопасности и в части сетевого оборудования.
Например, сейчас на отечественном рынке изобилие NGFW — межсетевых экранов нового поколения. Их часто презентуют, тестируют, вводят в эксплуатацию взамен иностранных решений. И что мы видим? Большое количество недовольства на тему того, что продукты отечественного производства часто не отрабатывают заявленные на бумаге характеристики: уровень производительности, пропускную способность, глубину фильтрации. Также существуют определенные сложности и особенности в администрировании таких средств.
Помимо несоответствия бумажных характеристик реальным, существует проблема с изначальной функциональной концепцией нового отечественного прикладного программного обеспечения. В настоящий момент рынок СрЗИ развивается от «регуляторики», а не от потребности бизнеса в реализации конкретного функционала или предотвращения реальных угроз. Функционал, который ранее покрывался импортными решениями, теперь представлен либо не в полной мере, либо не представлен вовсе. Например, некоторые отечественные SCADA, которые не умеют функционировать в режиме киоска.
Результат:
В итоге затруднена интеграция вновь проектируемых технологических решений или средств безопасности, так как достаточно сложно подобрать нужную конфигурацию и быть уверенным в ее функциональной состоятельности в боевых условиях. Большой разрыв между регуляторными и реальными рисками препятствует сохранению функционала спроектированных ранее СОИБ в полной мере, что приводит к вынужденному использованию дополнительных мер безопасности: организационных мер и компенсирующих мероприятий.
Решение:
Как правило, у компании есть два варианта. В первом случае в организации уже существует или формируется достаточный уровень экспертизы и компетенций. Во втором организация может воспользоваться экспертизой на аутсорсе. Под аутсорсом подразумеваем лаборатории, в условиях которых можно провести полноценный сравнительный анализ продуктов и применить в процессе пилотирования опыт на практике.
4 Особенности требований законодательства. Отраслевая специфика
Проблема:
Если с основными требованиями регуляторов все относительно ясно, то требования федеральных органов исполнительной власти (ФОИВ) все ещё вызывают некоторые вопросы. Например, в требованиях ФОИВ Минэнерго России между строк читается мысль об импортозамещении всего оборудования в рамках проекта технического перевооружения/модернизации АСУ ТП.
Согласно законодательным требованиям потребность в перекатегорировании возникает в случае значительной модернизации, при изменении показателей критериев значимости, а также вне зависимости от изменений не реже одного раза в 5 лет. Но иногда ситуация бывает более тривиальной и жизненной. Категорирование было проведено одним составом комиссии, а строить СОИБ пришли уже другие специалисты. Если их мнения не совпадают, глубина категорирования может быть признана избыточной или, наоборот, недостаточной.
Доверенные ПАКи. У самурая нет цели, только путь. Данный вопрос все ещё остается открытым. Пока нет полной ясности, действуем, исходя из текущих вводных.
Результат:
Вследствие стремительных внешних изменений проект корректируется чаще, чем это возможно произвести бесшовно, что неизбежно приводит к конфликту между исходными задачами и фактическим результатом.
Решение:
Каждая организация должна понимать, какие требования и в каком объеме нужно применить, какие риски она принимает на себя, и кто будет заниматься реализацией внедряемых мер. Compliance-контроль должен осуществляться на стороне владельца АСУ ТП непрерывно, возможно с привлечением аутсорсинговых ресурсов, так как законодательные требования могут быстро изменяться и иногда их сложно однозначно интерпретировать.
5 Требования к безопасной разработке
Проблема:
Согласно действующему законодательству в области безопасной разработки ПО, требования начинают действовать с момента модернизации, реконструкции или ремонта значимых объектов КИИ. В иных случаях объекты, которые не модернизируются или вовсе не являются субъектами КИИ, как правило, занимаются этим вопросом в «свободном формате».
Часто субъекты КИИ полагаются на эшелонированную защиту, считая, что наличие защиты на нескольких уровнях программного обеспечения исключает необходимость в безопасной разработке.
Отсутствуют единые законодательные требования в части безопасной разработки. Есть рекомендации, которые позволяют каждому субъекту предъявить собственные требования.
Низкий уровень защищенности ППО. Требования к безопасности в продуктах учитываются крайне редко, например, логирование либо не происходит совсем, либо поток всех событий пишется в txt-файл.
Результат:
Предъявляемые заказчиком требования не всегда коррелируются с законодательными рекомендациями и желаемым результатом. В итоге имеем увеличение поверхности атак за счет отсутствия должного внимания к безопасной разработке.
Решение:
Приемлемый уровень безопасной разработки следует устанавливать с учетом законодательных требований и их адаптации к потребностям конкретной организации. Такие мероприятия могут быть произведены объектом самостоятельно или с привлечением стороннего консалтинга. Также существует возможность использования технических средств, обогащенных экспертизой. Например, Apsafe — платформа непрерывного анализа защищенности приложений.
6 Особенности обновлений ИТ и ИБ решений
Проблема:
Вендоры формируют достаточно амбициозные дорожные карты по развитию продуктовых линеек и с впечатляющей частотой выпускают как плановые, так и внеплановые релизы, а также обновляют политики лицензирования. В длительных проектах не всегда получается держать руку на «пульсе» каждого производителя.
Периодически разработчики объявляют об окончании срока службы (EOS/EOL), предлагают рекомендации по миграции и анонсируют отказы от продления сертификатов соответствия.
Результат:
Сталкиваемся с необходимостью в сжатые сроки в рамках проектного цикла внедрять изменения как «на бумаге», так и «в полях». Это включает в себя замену производителей и решений в рамках модифицированных вендорских линеек, корректировки количества а, порой, и качества лицензий.
Решение:
В процессе подготовки к проектированию СОИБ необходимо уделить особое внимание объему реализованных проектов, составу компетенций исполнителя и его имиджу среди зарубежных и отечественных партнеров.
7 Человеческий фактор
Проблема:
Человеческий фактор является одной из самых серьезных уязвимостей системы информационной безопасности. Достаточно недальновидно применять сложные наложенные средства защиты там, где пароль прикреплен к монитору на цветном стикере.
Массовые проблемы в этой области:
Отсутствие явных границ зон ответственности АСУ ТП, ИБ, ИТ, недостаточный уровень внутренних коммуникаций.
Низкий уровень компетенций в области АСУ ТП, ИБ, ИТ.
Решение:
Эта проблема вечная, и решения она имеет достаточно неосязаемые:
Руководство организации следит за текущим уровнем знаний своих специалистов, обеспечивает непрерывное развитие их компетенций, поддерживает вовлеченность, устанавливает прозрачные границы работ и уровни ответственности между подразделениями.
Силами сторонней организации разрабатывается документации.
На этом ключевые проблемы подошли к концу, а мы постарались сделать однозначные выводы. В остальном… Времена изменились, и все, что было построено, спроектировано и введено в эксплуатацию в XX веке шло в ногу со временем, но со своим временем. В современных условиях необходимо заранее видеть свет в конце туннеля: горизонт планирования должен совпадать со сроком эксплуатации АСУ ТП, а это в среднем 5-10 лет. Или же просто обладать контактами тех, у кого уже четко сформирована дорожная карта туннеля, в конце которого виден свет 😊
P.S. Список выделенных проблем, конечно, не является исчерпывающим, в связи с этим приглашаем неравнодушных читателей в комментарии.
Автор: Анна Почечуева, пресейл-архитектор направления технической поддержки продаж
