Одна из основных проблем информационной безопасности, с которой сталкивается большинство организаций, заключается в том, что кибербезопасность зависит от армии разрозненных инструментов и технологий. Это не новость — мы говорим об этом уже много лет. Но это все еще актуально.
Возьмем, к примеру, управление киберрисками. Чтобы было ясно, я говорю об идентификации угроз и уязвимостей цифровой инфраструктуры, а затем о принятии правильных мер по снижению рисков.
В любой организации разумного размера управление киберрисками может легко включать в себя целый набор технологий, включая управление поверхностью атак (ASM), управление уязвимостями (VM), управление состоянием безопасности облака (CSPM), каналы информации о киберугрозах (CTI), базы данных управления конфигурацией (CMDB), тесты на проникновение, инструменты Red Teaming и многое другое.
Как все это объединить? Забудьте об ИИ, многие организации по-прежнему полагаются на ручные процессы и электронные таблицы.
Оглавление
Модель платформы кибербезопасности имеет ограничения
Поставщики технологий безопасности признают эту распространенную проблему и предлагают ряд решений. Первое (и самое привлекательное для поставщиков) — это понятие платформы. В рамках этой модели компании просто покупают все у одного поставщика и позволяют ему выполнять всю интеграционную работу за них. Это звучит привлекательно, и платформы могут работать для небольших организаций, но я вижу реальные ограничения для крупных предприятий.
Для крупного предприятия «платформа» — это кодовое слово для обозначения привязки к поставщику, чего организации стремятся избегать. Для крупной организации может потребоваться много месяцев или лет, чтобы перейти от распределенных инструментов к центральной платформе. Учитывая это, поставщикам платформ необходимо убедить множество разных людей, что эти усилия того стоят — сложная задача с учетом скептически настроенных специалистов по кибербезопасности.
Я считаю, что ландшафт угроз и связанные с ним изменения требований безопасности всегда будут опережать функциональность платформы. Как организации будут заполнять эти пробелы? Конечно, с помощью дополнительных точечных инструментов, разработанных для конкретных случаев использования.
Ошибочно полагаться на API для интеграции безопасности
Давайте посмотрим правде в глаза, крупные предприятия со сложными ИТ-инфраструктурами и прикладными средами, вероятно, не будут решать свои потребности в безопасности с помощью технологических платформ безопасности. Что же они будут делать вместо этого?
Не беспокойтесь, ведь индустрия технологий безопасности имеет еще одну стрелу в своем колчане — интерфейсы прикладного программирования (API). Разрозненные технологии могут взаимодействовать через свои API, таким образом, царит гармония кибербезопасности, верно?
Не верно! В теории подключение API звучит хорошо, но на практике оно крайне ограничено. Чтобы оно работало хорошо, поставщикам приходится открывать свои API для других поставщиков. Иногда они это делают, открывая одни API и не открывая другие, иногда они отказываются это делать. Даже если они открывают свои API, все равно есть проблемы.
Предположим, клиент хочет, чтобы его поставщик управления уязвимостями интегрировался с инструментами обнаружения и реагирования конечных точек (EDR), и у него установлена смесь Crowdstrike, SentinelOne и Trend Micro EDR. Тогда поставщику виртуальных машин нужно будет работать со всеми тремя поставщиками и интегрироваться с тремя различными наборами API. Много работы для общей цели.
Проблема коннектора в технологии кибербезопасности
Как я вижу, технология кибербезопасности в целом имеет фундаментальную проблему коннектора, которая сводится к отраслевому конфликту между альтруизмом и капитализмом. К сожалению для всех нас, капитализм побеждает с большим отрывом, поскольку поставщики защищают свои технологии ради конкурентного преимущества.
Некоторые поставщики могут выиграть битву, но мы проигрываем войну, делая кибербезопасность намного сложнее, чем она могла бы быть. Хотите пример? Насколько я понимаю, ни один из основных сканеров уязвимостей не будет принимать данные напрямую от сканеров-конкурентов. Поэтому, если в вашей среде есть несколько сканеров, вы сами должны интегрировать данные в рамках своей миссии по снижению рисков, даже если каждый сканер выполняет одни и те же основные функции. Еще больше ненужной работы.
Как устранить разрыв в кибериндустрии
Что можно сделать, чтобы исправить эту проблему? Нам нужно использовать открытый архитектурный подход, например, архитектуру платформы безопасности и аналитики ESG (SOAPA) или архитектуру сетки кибербезопасности Gartner (CSMA), и эти архитектуры зависят от создания и согласования некоторых открытых стандартов, включая:
- Стандарт формата данных. Меня воодушевляет открытая структура кибербезопасности (OCSF), но она долго ждала своего появления, и слишком много поставщиков не присоединились к усилиям. Я хотел бы видеть большее признание и больший прогресс.
- Стандартные API. Нет причин, по которым вам нужно говорить на нескольких языках, чтобы подключаться к разным инструментам в одной и той же технологической категории. Поставщики в каждой области или некий центральный орган управления/инженерии должны помогать создавать и управлять этими проектами.
- Стандарты для действий по исправлению. Если я хочу заблокировать индикатор компрометации или сгенерировать виртуальный патч в качестве компенсирующего элемента управления, мне нужно иметь возможность взаимодействовать со всеми разновидностями программного обеспечения безопасности конечных точек, брандмауэрами и системами IDS/IPS. Должен быть единый способ сообщить каждому элементу управления безопасностью о необходимости выполнения этого действия. Несколько лет назад я был оптимистичен в отношении стандарта под названием Open C2, выполняющего эту роль. Надеюсь, это происходит, но если это так, то мало кто об этом знает.
Я знаю, что усилия по стандартизации могут стать беспорядочными и превратиться в инженерные научные проекты. Хорошо, но я бы возразил этому аргументу, указав на стандарты STIX/ TAXII, которые обеспечивают последовательный способ описания и передачи данных разведки угроз. Таким образом, STIX/TAXII повысил эффективность и результативность анализа разведки угроз и последующих действий по снижению рисков.
Кто мог бы управлять стандартами кибербезопасности? Правительственное агентство или, возможно, MITRE, ENISA или какой-то совместный проект. Крупные организации в сфере финансовых услуг могли бы собрать своих инженеров по безопасности, разработать некоторые стандарты, а затем выдать поручение отрасли.
Я помню что-то вроде Jericho Forum в этом роде, сосредоточенное на сетевой безопасности в начале 2000-х. Наконец, технологические гиганты вроде Amazon, CrowdStrike, Microsoft или Palo Alto Networks могли бы стать лидерами, а затем опереться на других, чтобы запрыгнуть в вагон.
По моему скромному мнению, это было бы выигрышем для отрасли. Как при согласованных стандартах поставщики могли бы свободно сосредоточить свои ресурсы и конкурировать по характеристикам/функциональности.
В 1972 году в комиксе «Пого» была переработана известная цитата американского военно-морского командующего Оливера Хазарда Перри: «Мы встретили врага, и этот враг — мы сами».
К сожалению, я считаю, что это утверждение верно, когда речь идет об индустрии технологий кибербезопасности. Приоритет капитализма над альтруизмом значительно усложняет кибербезопасность и подвергает всех нас риску. Пришло время нам, как сообществу кибербезопасности, объединить усилия и потребовать сотрудничества. Во все более сложном и опасном мире наша цифровая безопасность зависит от этого.
Джон Олтсик