Цель кибериммунного подхода — не просто митигировать конкретные киберриски, а сделать так, чтобы архитектура решения в принципе не позволяла злоумышленнику нарушить цели безопасности. Ведь не так важно, какая именно уязвимость позволит провести атаку, — после релиза могут появиться и совсем новые эксплойты.
Поэтому при проектировании системы, которая будет безопасна by Design, стоит критическим взглядом посмотреть на ее архитектуру и задать себе несколько вопросов. Какие у нее есть уязвимые места? Что может пойти не так, если какую-то из компонент взломают? Что нужно изменить в архитектуре, чтобы взлом одной компоненты не привел к взлому всего устройства?
Важная особенность такого подхода заключается в том, что мы не пытаемся проанализировать все существующие угрозы и уязвимости и защититься от них. Вместо этого мы исходим из предпосылки в духе закона Мерфи: «Все, что может пойти не так, пойдет не так». То есть понимаем, что обо всех уязвимостях и возможных сценариях атак мы все равно не узнаем. Поэтому стараемся спроектировать дизайн системы так, чтобы устранить все ее небезопасные состояния.
Расскажу, как с таким подходом мы разрабатывали свой кибериммунный тонкий клиент (мини-компьютер для взаимодействия, например, с инфраструктурой виртуальных рабочих столов). Чтобы гарантировать достижение главной цели безопасности тонкого клиента, мы проделали следующие шаги.
В примере выше мы не защищались от конкретных уязвимостей в RDP-клиенте. Вместо этого мы сделали так, чтобы проэксплуатировать эти уязвимости и нарушить цели безопасности тонкого клиента стало практически невозможно. Одним словом, мы обезопасили устройство не только от известных угроз, но и от пока еще не существующих эксплойтов.
У такого подхода есть еще один приятный бонус. Когда в дальнейшем, имея готовый проект, мы проводим полноценное моделирование угроз, все «бреши в безопасности» (или их большинство), влияющие на достижение целей безопасности, оказываются уже закрыты. В результате проектировать ответы на угрозы становится значительно дешевле. Подробнее о моделировании можно прочитать в отдельном посте.
Цель кибериммунного подхода — не просто митигировать конкретные киберриски, а сделать так, чтобы архитектура решения в принципе не позволяла злоумышленнику нарушить цели безопасности. Ведь не так важно, какая именно уязвимость позволит провести атаку, — после релиза могут появиться и совсем новые эксплойты.
Поэтому при проектировании системы, которая будет безопасна by Design, стоит критическим взглядом посмотреть на ее архитектуру и задать себе несколько вопросов. Какие у нее есть уязвимые места? Что может пойти не так, если какую-то из компонент взломают? Что нужно изменить в архитектуре, чтобы взлом одной компоненты не привел к взлому всего устройства?
Важная особенность такого подхода заключается в том, что мы не пытаемся проанализировать все существующие угрозы и уязвимости и защититься от них. Вместо этого мы исходим из предпосылки в духе закона Мерфи: «Все, что может пойти не так, пойдет не так». То есть понимаем, что обо всех уязвимостях и возможных сценариях атак мы все равно не узнаем. Поэтому стараемся спроектировать дизайн системы так, чтобы устранить все ее небезопасные состояния.
Расскажу, как с таким подходом мы разрабатывали свой кибериммунный тонкий клиент (мини-компьютер для взаимодействия, например, с инфраструктурой виртуальных рабочих столов). Чтобы гарантировать достижение главной цели безопасности тонкого клиента, мы проделали следующие шаги.
В примере выше мы не защищались от конкретных уязвимостей в RDP-клиенте. Вместо этого мы сделали так, чтобы проэксплуатировать эти уязвимости и нарушить цели безопасности тонкого клиента стало практически невозможно. Одним словом, мы обезопасили устройство не только от известных угроз, но и от пока еще не существующих эксплойтов.
У такого подхода есть еще один приятный бонус. Когда в дальнейшем, имея готовый проект, мы проводим полноценное моделирование угроз, все «бреши в безопасности» (или их большинство), влияющие на достижение целей безопасности, оказываются уже закрыты. В результате проектировать ответы на угрозы становится значительно дешевле. Подробнее о моделировании можно прочитать в отдельном посте.