Избавиться от киберрисков раз и навсегда

Цель кибериммунного подхода — не просто митигировать конкретные киберриски, а сделать так, чтобы архитектура решения в принципе не позволяла злоумышленнику нарушить цели безопасности. Ведь не так важно, какая именно уязвимость позволит провести атаку, — после релиза могут появиться и совсем новые эксплойты.

Поэтому при проектировании системы, которая будет безопасна by Design, стоит критическим взглядом посмотреть на ее архитектуру и задать себе несколько вопросов. Какие у нее есть уязвимые места? Что может пойти не так, если какую-то из компонент взломают? Что нужно изменить в архитектуре, чтобы взлом одной компоненты не привел к взлому всего устройства?

Избавляемся от киберрисков: реальный пример

Важная особенность такого подхода заключается в том, что мы не пытаемся проанализировать все существующие угрозы и уязвимости и защититься от них. Вместо этого мы исходим из предпосылки в духе закона Мерфи: «Все, что может пойти не так, пойдет не так». То есть понимаем, что обо всех уязвимостях и возможных сценариях атак мы все равно не узнаем. Поэтому стараемся спроектировать дизайн системы так, чтобы устранить все ее небезопасные состояния.

Расскажу, как с таким подходом мы разрабатывали свой кибериммунный тонкий клиент (мини-компьютер для взаимодействия, например, с инфраструктурой виртуальных рабочих столов). Чтобы гарантировать достижение главной цели безопасности тонкого клиента, мы проделали следующие шаги.

1. Сформулировали главную цель безопасности: конфиденциальность и целостность данных, передаваемых между тонким клиентом и удаленным сервером.
2. Обратили внимание, что в обычной «функциональной» архитектуре достижению этой цели мешает большая поверхность атаки у той части системы, которая отвечает за взаимодействие с удаленным сервером. В нашем случае это был RDP-клиент, который обычно строится на базе довольно объемной (около 400 тысяч строк кода) популярной библиотеки FreeRDP. А такая солидная кодовая база — это всегда неизбежные ошибки и уязвимости.
3. Осознав эту проблему, мы скорректировали архитектуру системы: добавили небольшой компонент TLS Terminator для проверки сертификатов и поставили его «перед» RDP-клиентом.
4. Благодаря компактным размерам TLS Terminator мы смогли этот компонент тщательно проверить и таким образом удостовериться в его надежности.
5. В результате получился надежный «пропускной пункт», и сохранность данных перестала зависеть от уязвимостей в RDP-клиенте. Так мы частично решили изначальную задачу — гарантированно достичь главной цели безопасности.

Защита на будущее и приятный бонус

В примере выше мы не защищались от конкретных уязвимостей в RDP-клиенте. Вместо этого мы сделали так, чтобы проэксплуатировать эти уязвимости и нарушить цели безопасности тонкого клиента стало практически невозможно. Одним словом, мы обезопасили устройство не только от известных угроз, но и от пока еще не существующих эксплойтов.

У такого подхода есть еще один приятный бонус. Когда в дальнейшем, имея готовый проект, мы проводим полноценное моделирование угроз, все «бреши в безопасности» (или их большинство), влияющие на достижение целей безопасности, оказываются уже закрыты. В результате проектировать ответы на угрозы становится значительно дешевле. Подробнее о моделировании можно прочитать в отдельном посте.