Отражение технического директора о конференции RSA 2023
4 мая 2023 г.Привет. Я Мринал Вадхва, технический директор компании Ockam. На прошлой неделе на конференции RSA я встретил прекрасных старых друзей и много замечательных новых людей.
Во вторник днем я прошел через оживленный выставочный этаж, где коридор за коридором были представлены продукты, которые тщательно отслеживают, сканируют и тщательно изучают каждое событие, каждое сообщение журнала и каждый актив, чтобы как можно скорее обнаружить и пресечь любое подозрительное поведение.
Это было ярким напоминанием о том, что индустрия кибербезопасности превратилась в игру, в которой невозможно победить. Нас ждут серьезные сбои.
Сизифов удар-крота
В одном из стендов была аркадная игра «Ударь крота» (см. изображение выше), которая помогала визуализировать то, что они делают. Это довольно хорошая иллюстрация того, что делает большинство (возможно, более 90%) продуктов кибербезопасности; они сканируют некоторую часть поверхности вашей уязвимости, чтобы обнаружить аномальное поведение.
Некоторые сканируют сетевой трафик, некоторые отслеживают конечные точки, а третьи проверяют запросы API. Все они хотят прикончить следующего крота как можно быстрее.
Существуют тысячи продуктов, которые специализируются на сканировании определенных углов поверхности вашей уязвимости. Некоторые специализируются на конкретной отрасли, другие настроены на журналы конкретных популярных инструментов. Многие из них невероятно сложны и используют передовое машинное обучение и ИИ для обнаружения плохого поведения. Все они подчеркивают, что могут убить крота с большей точностью, чем их конкуренты.
Большинство продуктов для сканирования выполняют работу, как рекламируется. Эй, бить кротов невероятно приятно. Но если мы сделаем шаг назад, чтобы посмотреть на траекторию, мы заметим, что наша поверхность уязвимости растет намного быстрее, чем мы можем создавать сканеры для мониторинга каждой ее части. Наши личные и деловые данные, как это ни парадоксально, со временем становятся менее защищенными.
Подобно Сизифу из греческой мифологии, наша промышленность бесконечно катит большой валун вверх по крутому склону только для того, чтобы смотреть, как он катится обратно.
Поверхность нашей уязвимости растет в геометрической прогрессии
Чтобы развить интуицию, оставайтесь со мной, пока я занимаюсь математикой на салфетке с примерным приложением и поверхностью уязвимости данных, которыми оно управляет для пользователей.
В целях иллюстрации предположим, что вероятность того, что любой человек примет неправильное решение по безопасности, является фиксированной константой. С командой разработчиков из 10 человек поверхность уязвимости, созданная исходным кодом приложения, будет иметь площадь 10.
Если это приложение зависит, скажем, от 100 библиотек, и у каждой библиотеки есть 5 разработчиков, то площадь поверхности уязвимости, созданной этими библиотеками, составляет 100 * 5 = 500. Предположим, что приложение работает в контейнере, который содержит 100 пакетов операционной системы, и каждый пакет имеет 5 разработчиков, то площадь поверхности уязвимости, созданной пакетами ОС, также равна 100 * 5 = 500. Вместе зависимости создают поверхность уязвимости 500 + 500 = 1000.
Этот пример приложения будет работать в некоторой сети, и в этой сети, скажем, есть 9 других микросервисов. Если каждая служба имеет команду одинакового размера и дерево зависимостей, то общая площадь уязвимости данных нашего приложения составит 10 * 1000 = 10000.
Наше приложение также зависит от 9 облачных сервисов (базы данных, потоковая передача событий, шлюзы и т. д.), и каждый сторонний сервис также состоит из 10 микросервисов, работающих в сети. Общая площадь уязвимых мест данных нашего приложения, включая сторонние службы, становится равной 10 * 10 000 = 100 000.
Эта математика на салфетке, хотя и игнорирует пересечения поверхностей, является хорошей ментальной моделью для экспоненциального масштаба проблемы, с которой сталкиваются типичные современные приложения — десятки тысяч разработчиков, разработчиков платформ и системных администраторов. никогда не должны доставлять ошибку, чтобы данные нашего примера приложения оставались в безопасности.
Это неприемлемо; мы никогда не создадим достаточно сканеров, чтобы обнаружить все возможные ошибки, которые могут быть использованы злоумышленниками. Поверхности уязвимостей слишком велики и растут слишком быстро.
Еще больше усложняет ситуацию то, что типичная группа разработчиков приложений имеет ограниченный контроль над большей частью поверхности уязвимости, описанной выше. Они не могут отказаться от использования библиотек с открытым исходным кодом или от облачных сервисов.
Создание всего с нуля займет слишком много времени, будет стоить слишком много денег и, скорее всего, приведет к некачественным решениям.
Мы должны изменить игру
Вместо того, чтобы пытаться сканировать каждую часть экспоненциально расширяющейся поверхности, единственным разумным подходом является выбор дизайна, который полностью устраняет большие части нашей поверхности уязвимости. Мы должны сделать целые классы атак невозможными.
Мы должны создавать программное обеспечение таким образом, чтобы резко уменьшить размер потенциальных целей и ограничить радиус взрыва. Наше программное обеспечение должно быть конфиденциальным и безопасным по своей природе.
Раньше это было сложно и дорого. Следующие инструменты меняют правила игры:
* Языки со строгой типизацией, такие как Rust и Typescript, превращают инварианты в ошибки времени компиляции. Это уменьшает набор возможных ошибок, которые могут быть отправлены в рабочую среду, упрощая их обнаружение во время сборки.
* Языки, безопасные для памяти исключают возможность переполнения буфера, использования после освобождения памяти и других ошибок безопасности памяти. Вектор атаки, который, как известно, вызывает 60-70% уязвимостей высокой степени серьезности в больших кодовых базах C или C++. Rust обеспечивает эту безопасность без затрат производительности на сборку мусора во время выполнения.
* Методы обеспечения безопасности цепочки поставок, описанные в новых стандартах, таких как SLSA, помогают нам создавать элементы управления, которые гарантируют целостность артефактов в наших деревьях зависимостей. Это снижает вероятность использования вредоносными библиотеками, пакетами и образами контейнеров рабочих станций разработчиков, конвейеров сборки и сред выполнения.
* Криптографические ключи, хранящиеся на защищенном оборудовании, в сочетании с подходами без пароля и без токенов исключают возможность атак с использованием украденных паролей и токенов доступа.
* Взаимная аутентификация и детальная авторизация на уровне приложений с использованием таких инструментов, как Ockam, обеспечивают нулевое доверие к операционным сетям, VPN и VPC. Это удаляет другие приложения в той же сети из области уязвимости приложения.
* Прикладной уровень, сквозное шифрование всех данных и использование Ockam Защищенные каналы, устраняет сторонние сервисы с нашей поверхности уязвимости. Сквозные гарантии подлинности, целостности и конфиденциальности данных означают, что любая ошибка или неправильная конфигурация в брокере, балансировщике нагрузки или шлюзе не может поставить под угрозу данные нашего приложения.
Все эти подходы смещают безопасность влево и позволяют команде разработчиков приложения контролировать свойства безопасности и конфиденциальности своего приложения. Этой команде больше не нужно скрещивать пальцы и надеяться, что сторонний сервис не будет скомпрометирован; они могут просто сквозное шифровать данные при их прохождении через эту службу.
Такие дизайнерские решения превращают безопасность и конфиденциальность в проблемы, которые можно решать методично, вместо того, чтобы бесконечно катить большой валун в гору.
Регуляторное давление заставляет правила игры меняться
Еще один интересный эффект использования сканеров для обеспечения безопасности заключается в том, что затраты на защиту программного обеспечения перекладываются с поставщиков на потребителей программного обеспечения.
В прошлом поставщики программного обеспечения могли требовать, чтобы клиенты использовали свое программное обеспечение в пределах строго контролируемых сетевых границ, таких как VPN. Они смогли указать конфигурации среды, которые должны быть настроены именно так, чтобы их продукты были безопасными. Они смогли переложить расходы и обязательства по обеспечению безопасности на своих клиентов. По мере того, как угрозы безопасности возрастают, а уязвимости становятся неуправляемыми, как клиенты, так и регулирующие органы осознали, что такое перекладывание бремени неэффективно и слишком дорого.
Генеральный директор страховой компании Zurich недавно сообщил Financial Times, что кибератаки могут стать «нестраховыми». /a>». Глава CISA Джен Истерли и ее коллега Эрик Гольдштейн в феврале написали статью под названием Прекратите Бак о кибербезопасности утверждает: «Производители технологий должны нести ответственность за результаты безопасности своих клиентов». Они закладывают план фундаментального перехода к модели, в которой «кибербезопасность в конечном итоге будет обязанность каждого генерального директора и каждого совета директоров».
Этот переход ответственности к высшему руководству производителей технологий отражен в новых правилах в разных странах. Например, SEC предложила правила, требующие от компаний раскрывать инциденты кибербезопасности в течение четырех рабочих дней.
В этой неспокойной среде сообразительные компании превращают безопасность и конфиденциальность в конкурентное преимущество. Программные продукты, разработанные с учетом требований безопасности, привлекают клиентов, поскольку они позволяют создавать гораздо более безопасные системы, которые устраняют риски, упрощают соблюдение нормативных требований и значительно дешевле в эксплуатации.
Когда я выходил из выставочных залов RSAC, мне было очевидно, что индустрия кибербезопасности вот-вот увидит некоторые революционные изменения, и единственные компании, которые выживут в ближайшие несколько лет, — это те, которые примут эту новую реальность.
Оригинал