Для авиационной отрасли информационная безопасность постепенно перестает быть вопросом только документов и отчетности. Регулятор все чаще смотрит на то, как устроена инфраструктура на самом деле, кто имеет к ней доступ, насколько защищены рабочие места и что происходит с уязвимостями после их обнаружения. Новые риски добавляет и искусственный интеллект, который используют не только специалисты по защите, но и злоумышленники.
Эти вопросы обсуждали участники второй конференции «АвиаКод». В центре внимания оказались категорирование объектов, контроль подрядчиков, управление уязвимостями, применение ИИ и переход на российское программное обеспечение. «Компьютерра» разобралась, какие проблемы регулятор и представители отрасли считают сейчас наиболее существенными.
Категорирование должно отражать реальную инфраструктуру
За последний год требования к безопасности транспортной инфраструктуры заметно ужесточились. После вступления в силу новых требований организации должны были определить значимые объекты и подготовить меры по их защите. На практике этот процесс идет медленнее, чем рассчитывали регуляторы.
Под контролем и сопровождением находятся более 400 первичных организаций авиационной отрасли. По оценке ФСТЭК, около 60% из них уже начали выполнять требования законодательства. Примерно половина завершила категорирование и перешла к реализации защитных мер. Значимые объекты выявили 116 организаций.
При этом проверки показывают, что наличие документов еще не означает защищенную инфраструктуру. С начала года регулятор проверил 18 крупнейших транспортных организаций. Там выявили более 200 нарушений, причем больше половины касались уже не документации, а реальных мер защиты.
Елена Дербенко, начальник управления ФСТЭК России, отдельно остановилась на проблеме определения инфраструктуры. Организации не всегда точно понимают, какие системы входят в их периметр и как они связаны между собой. В результате система может формально не относиться к защищаемому контуру, но находиться внутри него и иметь доступ в интернет.
Поэтому категорирование должно помогать организации понять, какие системы она защищает, кто к ним подключается и какие риски возникают при такой конфигурации.
Проверка показывает разницу между отчетом и реальностью
Регулятор постепенно уходит от простой проверки документов к оценке того, как требования выполняются на практике. Недостаточно рассчитать уровень защищенности и указать его в отчете. Показатель должен соответствовать реальному состоянию инфраструктуры.
С 1 марта 2027 года расчет показателя уровня защищенности станет обязательным для организаций, владеющих значимыми объектами. ФСТЭК рекомендует использовать эту методику и для других систем, чтобы заранее оценивать состояние защиты.
Дербенко рассказала, что бывали случаи, когда организация заявляла высокий уровень защищенности, а проверка показывала менее 20% фактического значения. Причины могут быть разными. Например, при расчетах использовали неполные данные или информация от ИТ-подразделения и подрядчика не дошла до сотрудников, отвечающих за безопасность.
«Мы сталкивались с ситуациями, когда организация отчитывалась о высоком уровне защищенности, но при проверке оказывалось, что фактически он составляет меньше 20%. Часто проблема в исходных данных. ИТ-подразделение или подрядчик передают не всю информацию, а в итоге расчет не отражает реальное состояние инфраструктуры».
Елена Дербенко, начальник управления ФСТЭК России
Проблема здесь не только в ошибке в отчете. Если организация не знает, какие системы находятся внутри ее периметра, кто имеет к ним доступ и какие подключения идут извне, любой расчет будет лишь приблизительной оценкой.
Подрядчики тоже влияют на безопасность
Отдельный источник риска — подрядчики. Они могут получать привилегированный доступ к информационным системам и заниматься их администрированием. При этом заказчик не всегда контролирует, насколько защищены рабочие места самих внешних специалистов.
По данным ФСТЭК, примерно в 90% проверенных организаций, работающих в качестве подрядчиков, находили нарушения у сотрудников, которые имели доступ к значимым объектам, прикладным системам или средствам защиты.
Риск может возникнуть уже в момент подключения. Например, подрядчик работает с привилегированными правами с компьютера, который одновременно используется для обычного доступа в интернет. Если такое рабочее место взломают, злоумышленник потенциально получит доступ к внутренним системам.
Один из вариантов защиты заключается в том, чтобы давать подрядчику доступ только к необходимому сегменту инфраструктуры и контролировать его действия с помощью PAM-систем. Другой — заранее прописывать требования информационной безопасности в договоре и давать службе безопасности возможность проверять работу внешних специалистов.
Полностью отказаться от подрядчиков невозможно. Поэтому задача заключается в том, чтобы сделать их доступ ограниченным, понятным и контролируемым.
Уязвимость нельзя закрыть одной установкой обновления
С уязвимостями похожая история. Найти проблему и установить обновление недостаточно. После этого нужно еще раз проверить систему и убедиться, что уязвимость действительно устранена.
Если готового обновления пока нет, например при уязвимости нулевого дня, приходится временно снижать риск другими способами. Можно ограничить доступ к системе, изменить ее настройки или изолировать отдельный участок инфраструктуры.
Для авиационной отрасли это особенно сложно из-за большого количества систем и программ. Причем проблема может находиться не в самой критической системе. Например, взломанный компьютер администратора может стать входом во внутреннюю сеть, если с него разрешен доступ к другим ресурсам.
Поэтому следить приходится не только за значимыми объектами, но и за рабочими местами сотрудников, программами и всеми каналами, через которые к инфраструктуре получают доступ.
Российское ПО важно не только выбрать, но и поддерживать
Переход на российское ПО стал еще одной темой конференции. Для значимых объектов недостаточно просто заменить иностранную программу на отечественную. Нужно заранее понимать, кто будет выпускать обновления, исправлять уязвимости и поддерживать систему после внедрения.
Проблемы могут возникнуть и с российскими продуктами. Например, разработчик может уйти с рынка и перестать выпускать обновления. Тогда организации придется искать замену или самостоятельно поддерживать систему.
Для авиационной отрасли замена уже работающего ПО может быть сложной задачей. Разные программы связаны между собой, поэтому изменение одного компонента иногда требует дополнительных испытаний и настройки.
Участники конференции также обсуждали перечень рекомендованных программных решений для транспортной отрасли. При этом речь не должна идти о выборе одного обязательного продукта для всех. Гораздо важнее определить требования к программам и понять, каким характеристикам они должны соответствовать.
Такой подход позволит учитывать особенности разных организаций. Инфраструктура аэропорта, авиакомпании и обслуживающей компании отличается, поэтому одинаковый набор решений подойдет далеко не всем.
Безопасность зависит от всей организации
Еще одна проблема связана с взаимодействием ИТ- и ИБ-подразделений. Информационная безопасность не может существовать отдельно от ИТ. Именно технические подразделения управляют большей частью систем, на которых реализуются защитные меры. При этом в некоторых организациях ИТ и ИБ подчиняются разным руководителям, из-за чего их приоритеты могут расходиться.
Сергей Страхов, директор отраслевого центра компетенций по информационной безопасности «ЗащитаИнфоТранс», отметил, что эту проблему нужно решать на уровне руководства организации.
«Это задача руководителя организации — осознать эту проблему, эти риски и, в первую очередь, выстроить взаимодействие».
Сергей Страхов, директор отраслевого центра компетенций по информационной безопасности «ЗащитаИнфоТранс»
Постепенно регулятор обращает внимание не только на отдельные средства защиты, но и на то, насколько хорошо в организации выстроены процессы информационной безопасности. С 1 марта 2027 года показатель зрелости информационной безопасности станет обязательным для подрядных организаций в соответствующем контуре регулирования.
Для авиационной отрасли это особенно важно, поскольку к ее инфраструктуре имеют доступ разные внешние организации. Уязвимость может находиться не внутри аэропорта или авиакомпании, а у подрядчика, который подключается к их системам.
Сергей Страхов, директор отраслевого центра компетенций по информационной безопасности «ЗащитаИнфоТранс»
Поэтому оценивать приходится не только наличие средств защиты, но и то, насколько организация и ее подрядчики способны поддерживать безопасность на постоянной основе.
Выводы
Авиационной отрасли уже недостаточно просто подготовить документы и пройти проверку. Организация должна понимать, какие системы у нее работают, кто имеет к ним доступ, насколько они защищены и что происходит с найденными уязвимостями. То же касается подрядчиков, которые получают доступ к внутренней инфраструктуре.
Одновременно появляются новые проблемы. ИИ помогает быстрее находить уязвимости, поэтому времени на реакцию становится меньше. При переходе на российское ПО тоже недостаточно просто заменить один продукт другим. Нужно заранее понимать, кто будет его обновлять, исправлять ошибки и закрывать уязвимости.
В итоге безопасность становится постоянной работой, а не задачей перед очередной проверкой. Организациям приходится следить за инфраструктурой, доступами, подрядчиками и программами в течение всего срока их эксплуатации.
Читайте также: