стратегия
Популярный у инженеров принцип «работает — не трогай» многие годы применялся и в мире компьютеров. Теперь он стал непозволительной роскошью. Распространение кибератак, в том числе на научные и медицинские организации, ставит перед IT- и ИБ-службами настоящую дилемму. Чтобы защитить важное оборудование от атак, его программную часть надо обновить. Ведь устаревшее ПО на такой технике — это простые в эксплуатации уязвимости, примитивное или вовсе отсутствующее шифрование, рудиментарный контроль доступа, в общем — подарок для атакующего. Но само обновление ПО очень часто сопряжено с крупными расходами и риском остановки бизнес-процессов. Правда ли все так сложно и как решить эту проблему?
В чем риски обновлений
Многие системы безотказно работают годами и даже десятилетиями. Основной страх их бизнес-владельцев состоит в том, что процедура обновления может нарушить работу системы, а восстановить ее работоспособность будет невозможно. Подобные опасения не беспочвенны. Бывает, что люди, которые знали все подробности работы системы, давно уволились или ушли на пенсию, а документация утеряна или вовсе никогда не существовала. Это встречается нередко, но иногда проявляется в экстремальных формах. Например, в налоговой службе США до сих пор используются компьютеры 1970-х годов и программы на почти мертвом языке COBOL. Бывает, что поставщик техники был перепродан или поглощен другой компанией, вышел из бизнеса или обанкротился. Тоже не редкость — в этом году обанкротился гигант по производству банкоматов Diebold Nixdorf.
Во всех этих случаях искать техподдержки и помощи после сбоев в обновлении будет негде.
Более того, в случае длительной эксплуатации многих видов техники у нее образуются связи с другими системами в организации, и эти связи далеко не всегда очевидны и документированы. Поэтому отключение системы может спровоцировать каскадные сбои или отключения в других системах, которые довольно трудно предвидеть и предотвратить.
Все перечисленное приводит к неприятному выводу — восстановление после такого инцидента займет дни или недели, а стоимость простоя будет огромной.
Заградительная стоимость обновления
Даже если система не слишком связана с другими и хорошо документирована, ее обновление может быть несбыточной мечтой ИБ-команды из-за высокой стоимости проекта. Например, необходимость вывести из эксплуатации устаревшую ОС в аппарате для МРТ может потребовать покупки нового прибора. Его стоимость (порядка полумиллиона долларов) сама по себе очень велика. Но дороговизной томографа проблема не ограничивается. Для его установки требуется подъемный кран, иногда требуется разбирать часть стены. При этом нужно учитывать, что стены кабинета должны быть экранированы клеткой Фарадея, которую придется восстанавливать. Это уже не IT-проект, а стройка и ремонт немалого масштаба. Если же система сочетает глубоко устаревшее оборудование и столь же старое ПО, для замены «железа» потребуется переписать или купить новое ПО, что во многих случаях тоже является очень длительным и дорогостоящим проектом.
Компенсирующие меры
Как дорогой ретроавтомобиль держат в гараже, а ценные картины — в специальном коробе с контролируемым режимом, так и системы, которые невозможно ни заменить, ни полноценно обновить, требуют особого подхода к содержанию. Нужно принять все возможные меры к снижению поверхности атаки. Вот краткий перечень возможных компенсирующих мер по их защите:
Сегментация сети. Минимизировать риск кибератаки поможет выделение уязвимой устаревшей техники в отдельный сегмент сети. Нужно стремиться к высокой степени изоляции, вплоть до физического отделения сети и коммутационного оборудования. Если это не реалистично, нужно регулярно проверять, что конфигурация файрволов и маршрутизаторов продолжает поддерживать корректную изоляцию от «обычной» сети. Также необходимо отслеживать типовые нарушения регламента сотрудниками, например доступ с одного компьютера и в изолированную, и в общую сеть через разные сетевые интерфейсы.
Шифрование. Для систем, проводящих обмен информацией с другими компьютерами по устаревшим протоколам, желательно создать туннели (VPN), основанные на современных алгоритмах шифрования и аутентификации. Обмен данными вне туннеля должен быть заблокирован.
Обновления. Невозможность обновить систему до современной не означает, что на нее вообще нельзя ставить апдейты. Поэтапное обновление до последних доступных версий основного ПО и регулярное обновление баз для любых установленных систем защиты будут полезнее полной консервации.
Микросегментация процессов. Если бизнес-процесс на устаревшей системе допускает дробление, желательно оставить на ней только те части процесса, которые вообще невозможно перенести на более новое оборудование. Перенос даже частичной нагрузки на современную обновляемую платформу упростит защиту всего оставшегося. Например, снимки МРТ невозможно делать вне томографа, а вот их загрузку на сервер клиники, просмотр и интерпретацию уже можно проводить на более новых компьютерах.
Закрытый список приложений. Предыдущий совет позволяет снизить до минимума круг работ, выполняемых на устаревшей технике. Приложения и процессы, которые являются частью этих работ, можно внести в список разрешенных, а все остальные запретить. Это существенно снизит риски запуска ВПО или просто постороннего ПО, нарушающего стабильность системы. Такой механизм «запрета по умолчанию» можно реализовать при помощи специализированных защитных решений, способных работать в условиях экономии ресурсов.
Виртуализация. Для случаев, когда устаревшее ПО запускается на устаревшем же оборудовании, использование виртуальных машин может решить две проблемы: позволяет, во-первых, обновить как минимум оборудование, во-вторых, внедрить на уровне системы виртуализации и хост-системы ряд компенсирующих мер, таких как современный контроль доступа и шифрование. Этот совет может быть эффективным для очень старых систем обработки информации.
Минимизация доступа и привилегий. К устаревшей технике (а точнее, к ее компьютерам) необходимо давать доступ минимально необходимому числу сотрудников с предельно ограниченным набором прав. Если архитектура системы не предусматривает адекватной настройки прав и пользователей, можно попробовать внедрить эти ограничения на более ранней стадии доступа (вход в VPN, виртуальную машину и тому подобное), а также ограничить доступ чисто административными мерами (замки и охрана).
Разумеется, придется тщательно оценивать применимость каждой меры и риски, относящиеся к бесперебойной и безопасной работе техники при ее внедрении.
Задел на будущее
Применение компенсирующих мер к уже имеющейся устаревшей технике — далеко не вся работа для ИБ в ее отношении. ИБ-специалистам нужно иметь полный список морально устаревшей техники в организации и отслеживать моменты, когда ее замену инициируют по причинам бизнес-необходимости. Это удачный момент, чтобы провести апгрейд с учетом современных требований безопасности.
Что еще важнее, нужно, чтобы современные, вводимые сейчас в строй системы, которые когда-то станут устаревшими, не наследовали те же проблемы. Для этого нужно предъявлять соответствующие ИБ-требования при закупках оборудования и ПО: наличие механизмов регулярного и несложного обновления программных компонентов, документированная работа с дефектами и уязвимостями, в идеале — проектирование в философии secure by design.
Для ПО собственной разработки или ответвлений open source, которое современные организации все чаще используют в своей работе, крайне важно предъявлять высокие требования к документированию кода. В идеале производство документации становится такой же частью конвейера DevSecOps, как автотесты.
Советы