Применение модели "нулевого доверия" в оценке уровня кибербезопасности помогает предотвратить хакерские атаки

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

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

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

С точки зрения безопасности метод имеет свои преимущества и недостатки

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

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

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

Проверка и минимизация воздействия

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

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

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

В качестве примера предположим, что есть гипотетическая более молодая организация из среднего бизнеса. Под словом «моложе» подразумевается, что, возможно, прошло всего несколько лет с момента основания организации. Скажем, эта организация является «родной для облака», то есть на 100% экстернализована для всех бизнес-приложений и полностью построена на использовании облака.

Для такой организации совершенно необходимо отсутствие доверия. Поскольку она 100% экстернализована, у нее нет центров обработки данных или внутренних серверов, и она поддерживает только самые минимальные локальные технологии. Эта организация может прямо потребовать, чтобы никакие конфиденциальные данные не могли «жить» на конечных точках или внутри их офисной сети. Вместо этого все такие данные должны находиться в подмножестве известных, определенных облачных сервисов, которые явно одобрены для этой цели.

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

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

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

С другой стороны, заказчик также может разумно беспокоиться об аспектах физической безопасности, которые действительно относятся к среде поставщика услуг. Например, доступ посетителей к объектам, где данные клиентов могут просматриваться на экране, даже если данные там не хранятся. Они могут представить себе сценарий, например, когда неавторизованный посетитель в офисе может "увидеть визуально" данные, когда они выводятся на экран легитимным пользователем.

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

Принципиальные стратегии

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

С точки зрения поставщика услуг следует помнить о трех полезных принципах: 1) быть готовым, 2) демонстрировать подтверждение ваших предположений и 3) подтверждать свои утверждения документацией.

Под «предстоящим» я подразумеваю готовность поделиться информацией, выходящей за рамки того, о чем мог бы спросить покупатель. Если руководитель предоставляет облачное SaaS, как в приведенном выше примере, это может означать, что он готов делиться информацией, выходящей за рамки определенного набора элементов, запрошенных клиентом. Это позволяет ему «обобщать» информацию даже с точки зрения использования стандартных результатов. Например, можно рассмотреть возможность участия в реестре CSA STAR, подготовить стандартные артефакты для сбора информации, такие как CSA CAIQ, SIG для стандартизированной контрольной оценки Shared Assessments или HITRUST Third Party Assessment Program в сфере здравоохранения.

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

Последний пункт наличия документации означает документирование модели, которая поддерживается на предприятии. Например, если можно предоставить архитектурный документ, описывающий конкретный подход: почему он применяется, анализ рисков, который выполнен заранее, средства контроля для проверки и т. д. 

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

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

По  материалам: Technewsworld