Спустя ровно месяц после глобального сбоя в работе устройств с системой Windows, когда стали понятны его последствия, можно проанализировать причины и сделать выводы.
Сначала о последствиях. Инцидент с CrowdStrike коснулся 8 миллионов виртуальных машин под управлением ОС Windows, развернутых в облачной платформе Microsoft Azure. Инцидент был признан одним из крупнейших за все время наблюдения. Он привел к отменам и задержкам авиарейсов, сбоям в банковских операциях, в работе крупных морских портов и экстренных служб, в системах записей в медицинские учреждения. По текущим оценкам, финансовый ущерб для компаний составил в $5,4 млрд, не учитывая потери самой Microsoft.
Теперь о причинах. Известно, что причина сбоя – ошибка в обновлении Falcon Sensor – приложения для кибербезопасности платформы CrowdStrike. Falcon Sensor работает на уровне ядра операционной системы Windows, поэтому ошибка в нем привела к «синему экрану смерти» на миллионах Windows-машин.
Из произошедшего инцидента можно сделать два важных вывода. Первый – использование дополнительных (наложенных) средств защиты, которым в данном случае является приложение Falcon Sensor, не отменяет необходимость встраивать безопасность глубоко в архитектуру систем, т.е. следовать подходу Secure by Design. Второй вывод – подход Secure by Design касается не только прикладного кода поверх операционных систем, но и самих операционных систем. Рассмотрим эти выводы подробнее.
Как показал инцидент с CrowdStrike, средства безопасности – которым в данном случае является приложение Falcon Sensor – сами по себе могут служить источником неприятностей. Средства безопасности часто интегрируются в систему на очень низком уровне, обладают большими привилегиями или даже используют недокументированные возможности – обратите, например, внимание на то, что вызвать BSOD на Windows не так-то просто. Именно поэтому ошибки в них могут приводить к таким серьезным последствиям.
Это, конечно, не отменяет важности средств безопасности – часто без них просто не обойтись. Это говорит о другом.
О том, что в современном мире полагаться на одни только внешние (наложенные) средства безопасности – антивирусное ПО, экраны, средства мониторинга и т.п. – при этом используя изначально (конструктивно) небезопасные системы, получается все хуже в силу высокой связности систем.
Помимо этого, инцидент вскрывает вопрос тестирования. Почему ошибка в Falcon Sensor оказала столь драматический эффект? Да, во многом это было связано с проблемами в процедурах тестирования компании CrowdStrike. Но фундаментальная причина заключается в том, что в силу высокой связности современных систем, 100-процентное покрытие тестами на реальных сценариях становится слишком сложным и дорогим. В данном случае, проблемы с одним модулем системы привели к тому, что все вокруг него начало сыпаться как карточный домик. Такой же эффект может иметь и атака на отдельный компонент, а не просто его дисфункция. И решить эту проблему можно, только если правильным образом проектировать системы, закладывая безопасность глубоко в их дизайн и архитектуру.
Общий вывод из сказанного – необходимо следовать философии Secure by Design. Если задуматься, такой подход выглядит естественно, но пока он применяется преимущественно в узкоспециализированных сферах, чаще всего в системах, где критична физическая безопасность (safety). Широкого применения Secure by Design пока не нашел, хотя в индустрии ведутся активные работы по его «приземлению».
При этом, еще раз отметим, что подход Secure by Design, конечно, не отменяет важности и не противоречит использованию наложенных средств безопасности. В зависимости от области применения они могут дополнять друг друга. Например, один из наших продуктов – IoT-шлюз – спроектированный конструктивно безопасным, имеет в своем арсенале систему обнаружения вторжений (IDS/IPS), межсетевой экран, функции программного диода данных, технологии безопасной загрузки и обновления, которые усиливают его «архитектурную» безопасность.
Философия Secure by Design требует конкретных подходов. Мы в «Лаборатории Касперского» создаем собственную методологию, которая называется кибериммунитет. Она объединяет в себе лучшие мировые практики с нашим 25-летним опытом в кибербезопасности и позволяет создавать конструктивно безопасные продукты.
Инцидентс CrowdStrike также подтвердилналичие серьезных проблем, связанных с архитектурой монолитных операционных систем, в данном случае, Windows.
Монолитная архитектура предполагает работу драйверов и сторонних приложений (в данном случае это был Falcon Sensor) на уровне ядра. Ошибки в коде таких приложений могут вызывать полную потерю работоспособности системы или сделать их абсолютно беззащитными перед целенаправленной атакой. Поэтому сегодня активно развиваются микроядерные операционные системы, которые выносят сторонние драйвера и приложения за пределы ядра в пространство пользователя. К известным примерам микроядерных операционных систем относятся: Fuchsia от Google, QNX от Blackberry, MINIX 3, seL4.
За счет своей архитектуры микроядерная ОС характеризуется большей безопасностью. Так, например, в одном независимом исследовании говорится, что 96% критичных эксплойтов Linux перестанут быть критичными в микроядерной архитектуре, 57% критичных эксплойтов Linux станут иметь низкий уровень критичности, большая часть которых будет устранена полностью в случае верифицированного микроядра, 29% всех эксплойтов Linux будут полностью устранены даже без верифицированного микроядра.
Таким образом, микроядерный подход позволяет следовать идеологии Secure by Design не только на уровне прикладного кода, но и на уровне операционной системы.
Мы в «Лаборатории Касперского» работаем над созданием KasperskyOS на базе собственного микроядра, строя на ней кибериммунные продукты, которые являются безопасными «от рождения».
Подробнее про наш подход можно почитать в цикле статей «Кибериммунный подход к проектированию».
Спустя ровно месяц после глобального сбоя в работе устройств с системой Windows, когда стали понятны его последствия, можно проанализировать причины и сделать выводы.
Сначала о последствиях. Инцидент с CrowdStrike коснулся 8 миллионов виртуальных машин под управлением ОС Windows, развернутых в облачной платформе Microsoft Azure. Инцидент был признан одним из крупнейших за все время наблюдения. Он привел к отменам и задержкам авиарейсов, сбоям в банковских операциях, в работе крупных морских портов и экстренных служб, в системах записей в медицинские учреждения. По текущим оценкам, финансовый ущерб для компаний составил в $5,4 млрд, не учитывая потери самой Microsoft.
Теперь о причинах. Известно, что причина сбоя – ошибка в обновлении Falcon Sensor – приложения для кибербезопасности платформы CrowdStrike. Falcon Sensor работает на уровне ядра операционной системы Windows, поэтому ошибка в нем привела к «синему экрану смерти» на миллионах Windows-машин.
Из произошедшего инцидента можно сделать два важных вывода. Первый – использование дополнительных (наложенных) средств защиты, которым в данном случае является приложение Falcon Sensor, не отменяет необходимость встраивать безопасность глубоко в архитектуру систем, т.е. следовать подходу Secure by Design. Второй вывод – подход Secure by Design касается не только прикладного кода поверх операционных систем, но и самих операционных систем. Рассмотрим эти выводы подробнее.
Как показал инцидент с CrowdStrike, средства безопасности – которым в данном случае является приложение Falcon Sensor – сами по себе могут служить источником неприятностей. Средства безопасности часто интегрируются в систему на очень низком уровне, обладают большими привилегиями или даже используют недокументированные возможности – обратите, например, внимание на то, что вызвать BSOD на Windows не так-то просто. Именно поэтому ошибки в них могут приводить к таким серьезным последствиям.
Это, конечно, не отменяет важности средств безопасности – часто без них просто не обойтись. Это говорит о другом.
О том, что в современном мире полагаться на одни только внешние (наложенные) средства безопасности – антивирусное ПО, экраны, средства мониторинга и т.п. – при этом используя изначально (конструктивно) небезопасные системы, получается все хуже в силу высокой связности систем.
Помимо этого, инцидент вскрывает вопрос тестирования. Почему ошибка в Falcon Sensor оказала столь драматический эффект? Да, во многом это было связано с проблемами в процедурах тестирования компании CrowdStrike. Но фундаментальная причина заключается в том, что в силу высокой связности современных систем, 100-процентное покрытие тестами на реальных сценариях становится слишком сложным и дорогим. В данном случае, проблемы с одним модулем системы привели к тому, что все вокруг него начало сыпаться как карточный домик. Такой же эффект может иметь и атака на отдельный компонент, а не просто его дисфункция. И решить эту проблему можно, только если правильным образом проектировать системы, закладывая безопасность глубоко в их дизайн и архитектуру.
Общий вывод из сказанного – необходимо следовать философии Secure by Design. Если задуматься, такой подход выглядит естественно, но пока он применяется преимущественно в узкоспециализированных сферах, чаще всего в системах, где критична физическая безопасность (safety). Широкого применения Secure by Design пока не нашел, хотя в индустрии ведутся активные работы по его «приземлению».
При этом, еще раз отметим, что подход Secure by Design, конечно, не отменяет важности и не противоречит использованию наложенных средств безопасности. В зависимости от области применения они могут дополнять друг друга. Например, один из наших продуктов – IoT-шлюз – спроектированный конструктивно безопасным, имеет в своем арсенале систему обнаружения вторжений (IDS/IPS), межсетевой экран, функции программного диода данных, технологии безопасной загрузки и обновления, которые усиливают его «архитектурную» безопасность.
Философия Secure by Design требует конкретных подходов. Мы в «Лаборатории Касперского» создаем собственную методологию, которая называется кибериммунитет. Она объединяет в себе лучшие мировые практики с нашим 25-летним опытом в кибербезопасности и позволяет создавать конструктивно безопасные продукты.
Инцидентс CrowdStrike также подтвердилналичие серьезных проблем, связанных с архитектурой монолитных операционных систем, в данном случае, Windows.
Монолитная архитектура предполагает работу драйверов и сторонних приложений (в данном случае это был Falcon Sensor) на уровне ядра. Ошибки в коде таких приложений могут вызывать полную потерю работоспособности системы или сделать их абсолютно беззащитными перед целенаправленной атакой. Поэтому сегодня активно развиваются микроядерные операционные системы, которые выносят сторонние драйвера и приложения за пределы ядра в пространство пользователя. К известным примерам микроядерных операционных систем относятся: Fuchsia от Google, QNX от Blackberry, MINIX 3, seL4.
За счет своей архитектуры микроядерная ОС характеризуется большей безопасностью. Так, например, в одном независимом исследовании говорится, что 96% критичных эксплойтов Linux перестанут быть критичными в микроядерной архитектуре, 57% критичных эксплойтов Linux станут иметь низкий уровень критичности, большая часть которых будет устранена полностью в случае верифицированного микроядра, 29% всех эксплойтов Linux будут полностью устранены даже без верифицированного микроядра.
Таким образом, микроядерный подход позволяет следовать идеологии Secure by Design не только на уровне прикладного кода, но и на уровне операционной системы.
Мы в «Лаборатории Касперского» работаем над созданием KasperskyOS на базе собственного микроядра, строя на ней кибериммунные продукты, которые являются безопасными «от рождения».
Подробнее про наш подход можно почитать в цикле статей «Кибериммунный подход к проектированию».
