В связи с растущим риском нарушений личных данных, как это видно в недавних атаках программ-вымогателей и цепочек поставок, предприятия начинают осознавать необходимость защиты личных данных. По мере того, как они оценивают, как лучше всего усилить защиту идентификации, часто возникает необходимость довольствоваться функциями или модулями безопасности, включенными в корпоративные пакеты от того же поставщика, который предоставляет обеспечение безопасности идентификации (Identity Security) и/или управления идентификацией и доступом (IAM).
Типичный пример можно увидеть в организациях с пакетом Microsoft E3/E5, который уже использует Active Directory + Azure AD в качестве уровня идентификации. Они могут согласиться на Microsoft Defender для идентификации и/или защиту идентификации Azure AD для удовлетворения своих потребностей в безопасности идентификации.
Хотя использование нескольких продуктов от одного и того же поставщика в составе корпоративного пакета обычно экономически выгодно, бывают случаи, когда такая компрометация может привести к дорогостоящим и катастрофическим нарушениям — и сочетание идентификации и безопасности идентификации является одним из них. Клиенты часто не в полной мере понимают, на что следует обращать внимание в решении для защиты идентификационных данных.
Прежде чем исследовать причины ошибочности этого подхода, давайте рассмотрим несколько определений.
Различие между IAM и Identity Security
IAM является частью стратегии ИТ-безопасности организации, которая фокусируется на управлении цифровыми удостоверениями и доступом пользователей к данным, системам и другим ресурсам. Технологии IAM хранят удостоверения и управляют ими для обеспечения возможностей единого входа (SSO) или многофакторной аутентификации (MFA), но не предназначены в первую очередь как решение безопасности для обнаружения и предотвращения нарушений.
Identity Security, с другой стороны, представляет собой комплексное решение, созданное с единственной целью обнаружения и предотвращения нарушений, связанных с идентификацией, особенно когда злоумышленникам удается обойти устаревшие меры безопасности.
Идеальное решение для защиты удостоверений должно быть частью более широкой платформы безопасности с глубоким обзором каждого уровня предприятия, подверженного взлому, для более точного обнаружения и реагирования, включая конечные точки, облачные рабочие нагрузки, удостоверения и данные.
Подводные камни при покупке IAM и Identity Security у одного и того же поставщика
Конкурирующие интересы
Это может показаться пустяком, но при принятии решений о закупках в области кибербезопасности часто упускается из виду области конкурирующих интересов поставщика. Должно быть четкое разделение ответственности. В бухгалтерском учете аудитор проводит независимую проверку, чтобы убедиться, что числа верны, а в разработке программного обеспечения код тестируется после того, как его написали разработчики.
Та же концепция применима к безопасности: когда вы покупаете удостоверение и защиту удостоверения у одного и того же поставщика, вы игнорируете этот основной принцип обеспечения нейтралитета.
Microsoft Active Directory построена на основе устаревшей технологии, которой уже несколько десятков лет, и считается одним из самых слабых звеньев в стратегии киберзащиты организации. Каждый год обнаруживаются новые уязвимости AD, в том числе недавняя, которая может привести к полной компрометации домена за считанные секунды.
В то же время это одно из наиболее широко используемых хранилищ удостоверений: более 90% организаций из списка Fortune 1000 по-прежнему полагаются на него, что делает Active Directory очень привлекательной мишенью для атак на основе удостоверений.
Как поставщик удостоверений Microsoft имеет некоторые обязательства по предоставлению своим клиентам исправлений для уязвимостей AD, но это только одна часть уравнения. Если Microsoft также является поставщиком средств защиты личных данных, она также должна оперативно предоставлять возможности обнаружения и исправления, чтобы злоумышленники не могли запускать атаки, используя уязвимости в ее продуктах — но это область, в которой она неоднократно подводила своих клиентов.
Напротив, когда безопасность идентификации обеспечивается нейтральным, ориентированным на безопасность поставщиком, этот конкурирующий интерес устраняется. Единственной целью поставщиков решений для обеспечения безопасности является защита клиентов от взломов и предоставление клиентам возможностей упреждающего обнаружения и исправления, а не исправление уязвимостей в продуктах для идентификации.
Другой областью конкурирующих интересов является интеграция. Предложение по защите удостоверений должно быть способно интегрироваться с широким спектром продуктов для удостоверений и обеспечивать видимость, чтобы обеспечить унифицированное представление удостоверений.
Однако, когда поставщик удостоверений также предоставляет уровень безопасности удостоверений, нет никакого стимула для интеграции с другими поставщиками удостоверений, чтобы обеспечить единую панель управления, которая дает представление о нескольких хранилищах удостоверений в гибридной среде. Разница очевидна с Microsoft Defender для идентификации — он ориентирован на Microsoft, тогда как продукты других компаний работают не только с Active Directory и Azure AD, но и с другими лучшими в своем классе поставщиками IAM/MFA, такими как Okta, Ping, Duo и другие.
Отсутствие глубокой безопасности
Хотя слово «идентификация» является частью «безопасности идентификации», акцент должен делаться на безопасности. Идеальное решение для защиты удостоверений должно быть частью более широкой платформы безопасности, которая может сопоставлять информацию о безопасности из нескольких источников.
Облачная система экспертов по безопасности сопоставляет триллионы событий безопасности в день с индикаторами атаки, ведущей в отрасли аналитикой угроз и корпоративной телеметрией со всех конечных точек клиентов, рабочих нагрузок, удостоверений и данных. Этот лазерный фокус на безопасности, включающий широкий спектр данных об атаках, позволяет продуктам обеспечивать сверхточное обнаружение, а также автоматическую защиту и устранение.
Такого целенаправленного внимания к безопасности трудно достичь такому гиганту программного обеспечения, как Microsoft, у которого многолетний технический долг от устаревших продуктов, а также широкий спектр новых предложений, начиная от облачной инфраструктуры и услуг и заканчивая программным обеспечением, оборудованием и играми.
Благодаря своему устаревшему подходу из дооблачного мира Microsoft постоянно догоняет, чтобы исправить недавно обнаруженные уязвимости в своих продуктах. На протяжении многих лет компания сталкивалась с целым рядом проблем безопасности, включая компрометацию цепочки поставок AD, уязвимость PrintNightmare и распространенные неправильные настройки AD, которыми пользуются злоумышленники.
Этот недостаток еще раз проявился в недавнем эксплойте noPac, который позволил злоумышленникам объединить две критически важные CVE, относящиеся к Active Directory (CVE-2021-42278 и CVE-2021-42287), что привело к повышению привилегий с прямым путем к скомпрометированному домену.
В то время как решение от экспертов по безопасности автоматически обнаруживает попытки использования этих уязвимостей и может блокировать noPac с помощью простой политики для принудительного применения MFA, в ответ Microsoft предоставила исправления для устранения этих уязвимостей в своем собственном продукте, но ответственность за их применение лежит на клиенте: патчи в каждый контроллер домена AD.
Привязка к поставщику
Конкурирующие интересы становятся более сложными, когда поставщик, предоставляющий уровень идентификации, также продает облачную инфраструктуру и заинтересован в перемещении клиентов в свое облако.
Столкнувшись с недавно обнаруженной уязвимостью или архитектурным недостатком в своем локальном уровне идентификации (например, Active Directory), поставщик может просто предложить клиентам начать использовать свой облачный уровень идентификации (например, Azure AD), чтобы избежать уязвимости.
Это практически невозможно для клиентов, которые построили уровни приложений поверх своей инфраструктуры AD, на миграцию которых ушли бы годы. Что еще более важно, переход в облако никак не защищает их от злоумышленников, которые в настоящее время используют уязвимости AD, чтобы сеять хаос.
Интересно, что недавний отчет Microsoft показал, что использование MFA в Azure AD остается низким, при этом для большинства удостоверений Azure AD требуются только имя пользователя и пароль, что подчеркивает тот факт, что Azure AD не является волшебным средством для решения проблем безопасности AD.
Привязка к поставщику наносит ущерб клиентам, не позволяя им воспользоваться преимуществами современной мультиоблачной реальности. Этому можно противопоставить решение для защиты личных данных от нейтрального поставщика, который не заинтересован в подталкивании клиентов к конкретной облачной инфраструктуре. Он также предоставляет организациям более длительные сроки для планирования и реализации миграции в гибридное облако, не беспокоясь о нарушениях во время перехода.
Наконец, подход к обеспечению безопасности с несколькими поставщиками идентификации дает предприятиям гибкость в выборе поставщика MFA. Такое решение обеспечивает готовую интеграцию с большинством ведущих поставщиков MFA, включая Okta, Duo и Google Authenticator, предоставляя организациям беспроблемный опыт MFA, вместо того, чтобы привязываться к одному решению MFA, как с Microsoft.
Почему безопасность личных данных должна быть отделена от личных данных?
Современные атаки, такие как программы-вымогатели, обычно основаны на идентификационных данных, и надежное решение для защиты идентификационных данных должно быть ключевым компонентом вашей общей системы безопасности. Использование решения для защиты идентификационной информации, включенного в корпоративный пакет от поставщика идентификационной информации, приведет к ухудшению результатов в плане безопасности и повысит риск взлома.
Ваши потребности в защите личных данных будут лучше удовлетворяться решением от нейтрального поставщика средств обеспечения безопасности для защиты всех критических областей корпоративного риска — конечных точек, облачных рабочих нагрузок, личных и корпоративных данных.
Важно отметить, что не только вредоносное ПО и вирусы влияют на работу сайта, а и многие другие факторы. Но, какова бы ни была причина, по которой страница сайта не открывается, например проблемы с базой данных или сервером, DDoS-атаки или вирусы, важно контролировать доступность сайта для посетителя. Ситуация, при которой пользователь не может открыть страницу вашего сайта, отрицательно влияет на поднятие сайта в поиске (поисковой выдаче) и оставляет негативное впечатление о вашем сайте у посетителя. Вы теряете потенциальных клиентов, а значит и деньги. Используйте хороший сервис, например BAILRY для постоянного контроля (проверки) доступности сайта. Сервис предоставляет как бесплатную регулярную (периодическую) проверку доступности сайта, так и платную услугу - для постоянного контроля доступности сайта.
Компания Mainton - разработка и тестирование программного обеспечения под заказ, SEO и реклама в интернете с 2004 года.