Управление приложениями на основе минимально необходимых привилегий - урок, полученный в результате инцидента с SolarWinds Orion

Изощренная атака, направленная на проникновение в  SolarWinds Orion и последующую компрометацию тысяч ее клиентов, поражает своей масштабностью и потенциальными последствиями.

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

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

Связь атаки SolarWinds и привилегий приложений

Ни один вендор не может гарантировать, что его решение полностью предотвратило бы атаку на SolarWinds, и нам следует остерегаться подобных заявлений. При этом компании могут предпринять стратегические шаги по предотвращению данного типа атак в будущем, если они осознают и решат одну из фундаментальных проблем управления унаследованной инфраструктурой. Эта основная проблема безопасности заключается в необходимости того, чтобы любое приложение имело неограниченный доступ ко всему, что находится в сети, или, с точки зрения управления привилегированным доступом, глобальный разделяемый доступ с правами администратора или root.

Что такое глобальный разделяемый административный доступ? Это неограниченный доступ учетной записи (записей) к среде.  Обычно это означает, что для работы приложения без ограничений нужно сделать исключения из политик безопасности. Например, учетная запись может быть включена в список разрешенных в системах контроля приложений и исключена из антивирусного программного обеспечения, поэтому она не блокируется и не помечена флажком. Учетная запись может работать от имени пользователя, самой системы или приложения на любом активе или ресурсе в среде. Многие специалисты в области кибербезопасности называют этот тип доступа "god privileges", он несет в себе массивный, неснижаемый риск.

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

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

В случает с SolarWinds именно это и произошло. Само приложение было скомпрометировано через автоматическое обновление, и злоумышленники воспользовались неограниченным привилегированным доступом в среде жертвы с помощью этого приложения. Атакующие могли выполнять практически любые задачи, замаскированные под SolarWinds, и даже очень старались не выполнять их на системах, на которых присутствуют средства мониторинга и обеспечения безопасности продвинутых вендоров. Таким образом, становится очевидным следующее: если вредоносный код достаточно изощрен, чтобы обходить решения безопасности и выполнять его только на тех объектах, где он может избежать обнаружения, он будет делать это, используя глобальные разделяемые административные привилегии. Ни одно решение не смогло бы обнаружить и заблокировать такую атаку.

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

Как предотвратить или устранить атаки, в организации которых задействованы унаследованные приложения

Здесь возникает большой вопрос: как можно модернизировать наши среды и не зависеть от приложений и учетных записей, требующих чрезмерных привилегий, что небезопасно?

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

Если вы считаете, что нарушения SolarWinds - это самое худшее, что когда-либо случалось в сфере кибербезопасности, возможно, вы правы. Для тех профессионалов в области кибербезопасности, которые помнят Sasser, Blaster, Big Yellow, Mirai и WannaCry, объем воздействий на систему сравним, но цель и полезная нагрузка этих червей не идет ни в какое сравнение с атакой SolarWinds.

Серьезные угрозы существуют уже десятки лет, но никогда прежде мы не видели, чтобы ресурс был атакован так изощренно, что все потенциальные жертвы и последствия атак нам не известны до сих пор. Когда Sasser или WannaCry поражал системы, их владельцы знали об этом. Даже в случае вирусов-вымогателей вы узнаете о последствиях в течение короткого периода времени.

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

К сожалению, это не является уязвимостью, которая требует исправления, а скорее несанкционированное использование возможностей приложения, которому нужны эти привилегии. 

Итак, с чего начать?

Прежде всего нам нужно идентифицировать и обнаружить все приложения в нашей среде, которым нужны такие чрезмерные привилегии:

• Используя инструмент обнаружения класса «enterprise», определите, какие приложения имеют одну и ту же привилегированную учетную запись на нескольких системах. Учетные данные, скорее всего, являются общими и могут быть использованы для горизонтального распространения.
• Сделайте инвентаризацию группы «Domain Administrators Group» и идентифицируйте все присутствующие учетные записи приложений или служб. Любое приложение, которому нужны привилегии администратора домена, представляет собой высокий риск.
• Просмотрите все приложения, которые находятся в вашем глобальном списке исключений антивируса (по сравнению с исключениями на определенных узлах). Они будут задействованы в первом и самом важном шаге вашего стека безопасности конечных точек - предотвращении вредоносного ПО.
• Просмотрите список программного обеспечения, используемого на предприятии, и определите, какие привилегии необходимы приложению для работы и выполнения автоматических обновлений. Это может помочь определить, нужны ли привилегии локального администратора или учетные записи локального администратора для корректной работы приложения. Например, обезличенная учетная запись для повышения привилегий приложения может иметь учетную запись на локальном узле только для этой цели.

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

• Обновить приложение до более новой версии решения
• Выбрать нового вендора для решения проблемы
• Перевести рабочую нагрузку в облако или на другую инфраструктуру

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

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

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

Если у вас есть инструменты, для управления которыми требуются такие глобальные разделяемые административные учетные записи, то задачей первостепенной важности на 2021 год должна стать замена этих инструментов или их обновление. Убедитесь, что решения, которые вы покупаете, разработаны вендорами, уже избавившимися от этой угрозы.

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

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

Снижение киберриска в 2021 году и дальше: следующие основные шаги

Любая организация может быть мишенью злоумышленников, а любое приложение с чрезмерными привилегиями может быть использовано против всей компании. Инцидент с SolarWinds должен побудить всех нас пересмотреть и идентифицировать те приложения, работа которых сопряжена с рисками чрезмерного привилегированного доступа. Мы должны определить, как можно смягчить угрозу, даже если устранить ее прямо сейчас невозможно.

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

Источник ►