Об авторе: Роман Карпов, глава комитета по информационной безопасности АРПП «Отечественный софт», генеральный директор компании Axiom JDK
Почему в ближайшие годы главным объектом внимания служб ИБ станет не сама информационная система, а жизненный цикл программного обеспечения.
В последние годы в сфере безопасности критической информационной инфраструктуры (КИИ) произошли существенные изменения. Развивается нормативная база, расширяются требования к субъектам КИИ, усиливается внимание к вопросам технологической независимости, доверенности программного обеспечения и устойчивости эксплуатации критически важных систем. При этом регуляторные изменения затрагивают не отдельные аспекты защиты информации, а практически весь жизненный цикл цифровой инфраструктуры — от выбора программного обеспечения до его сопровождения и вывода из эксплуатации.
Однако одновременно меняется и сама природа рисков. Долгое время информационная безопасность строилась вокруг защиты информационных систем. Предполагалось, что если система спроектирована в соответствии с требованиями, оснащена необходимыми средствами защиты и прошла необходимые процедуры оценки, то её можно считать безопасной.
Сегодня такая модель постепенно перестаёт соответствовать реальности. Современное программное обеспечение больше нельзя рассматривать как статичный актив. Практически любая информационная система представляет собой постоянно развивающуюся совокупность компонентов, библиотек, платформ и сервисов. Она регулярно получает обновления, исправления ошибок и уязвимостей, интегрируется с другими системами, изменяет архитектуру и состав используемых компонентов. Одновременно меняются поставщики технологий, условия сопровождения и требования регуляторов. Это означает, что безопасность перестаёт быть характеристикой конкретной версии программного продукта. Она становится характеристикой процесса его постоянного изменения. Именно поэтому сегодня организациям необходимо смещать внимание с отдельных средств защиты на управление жизненным циклом программного обеспечения. Фактически речь идет о переходе от модели «защиты системы» к модели «управления изменениями». Такой подход требует ответа на четыре принципиальных вопроса.
1. Что используется?
Первое, что должна понимать организация, — каким программным обеспечением она фактически управляет. Речь идет не только о перечне установленных продуктов. Необходимо иметь достоверную информацию о составе ПО, используемых компонентах, зависимостях между ними, происхождении этих компонентов, их роли в работе критической инфраструктуры и степени влияния на устойчивость эксплуатации.
Практика показывает, что именно отсутствие такой прозрачности нередко становится причиной того, что обновления выполняются без оценки их последствий, а критически важные зависимости обнаруживаются уже после возникновения инцидентов.
2. Откуда это появилось?
Следующий вопрос касается происхождения программных компонентов. Сегодня недостаточно доверять только известности поставщика или наличию продукта в реестрах. Необходимо понимать, каким образом программное обеспечение создаётся и сопровождается, насколько зрелыми являются процессы разработки, каким образом устраняются выявленные недостатки, насколько предсказуем выпуск обновлений и как организовано сопровождение продукта.
По сути, объектом оценки становится уже не только программный продукт, но и организация процессов его создания и сопровождения. Именно этот аспект в последние годы становится одним из ключевых факторов оценки устойчивости цепочек поставок программного обеспечения.
3. Что изменилось?
Пожалуй, именно этот вопрос становится центральным. Любое изменение программного обеспечения потенциально меняет профиль риска организации. Обновление версии, замена библиотеки, подключение нового компонента, изменение конфигурации, переход на другую платформу или смена поставщика способны повлиять не только на работоспособность информационной системы, но и на выполнение обязательных требований безопасности. Поэтому управление изменениями перестаёт быть исключительно функцией подразделений эксплуатации. Оно становится частью системы обеспечения информационной безопасности.
Организация должна иметь возможность ответить на простые, но принципиальные вопросы: что именно изменилось, кто инициировал изменение, какие компоненты были затронуты, каким образом это влияет на другие системы и сохраняется ли соответствие установленным требованиям после внесённых изменений. Без такой управляемости безопасность неизбежно превращается в реакцию на уже произошедшие события.
4. Кто принимает решение?
Последний вопрос относится уже к управлению организацией. Изменения в программном обеспечении не должны приниматься исключительно техническими подразделениями или, наоборот, только службой информационной безопасности. Необходима единая система управления, в которой архитекторы, специалисты по эксплуатации, подразделения информационной безопасности, владельцы информационных систем и руководство организации принимают согласованные решения на основе оценки рисков и влияния изменений на критические процессы.
На практике именно отсутствие такого механизма становится одной из причин накопления технического долга, появления неконтролируемых изменений и снижения устойчивости цифровой инфраструктуры. Именно поэтому сегодня можно говорить о качественном изменении роли информационной безопасности. Если раньше её задачей была защита информационных систем, то теперь этого уже недостаточно. Защищать необходимо сам процесс их непрерывного изменения.
Заключение
В условиях постоянного развития программных продуктов, регулярных обновлений и усложнения цепочек поставок объектом управления становится весь жизненный цикл программного обеспечения — от выбора источника и оценки доверия поставщику до установки обновлений, контроля изменений и вывода системы из эксплуатации.
Это требует иного подхода к организации процессов внутри субъекта КИИ. Информационная безопасность должна стать не внешним контролёром, который проверяет уже принятые технические решения, а полноценным участником управления изменениями. Её задача — обеспечивать прослеживаемость происхождения программных компонентов, контроль обновлений, оценку влияния изменений на архитектуру и соответствие обязательным требованиям, а также поддерживать предсказуемость эксплуатации на протяжении всего жизненного цикла ПО.
В условиях усложнения цифровой инфраструктуры именно такая модель позволит обеспечить не только выполнение требований регуляторов, но и устойчивость функционирования критически важных систем. В конечном счёте зрелость субъекта КИИ будет определяться не количеством внедрённых средств защиты, а способностью организации управлять изменениями так же последовательно, как сегодня она управляет доступом, инцидентами или эксплуатацией инфраструктуры. Именно в этом, на мой взгляд, заключается следующий этап развития информационной безопасности.
