По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Определение проблемного пространства
Сетевые инженеры часто сталкиваются с проблемой слишком большого трафика для слишком малого канала связи. В частности, почти в каждом пути через сеть одно звено ограничивает весь путь, так же как один перекресток или одна дорога ограничивает поток трафика. Рисунок ниже иллюстрирует это.
На рисунке A обменивается данными с G, а B обменивается данными с E. Если каждая из этих пар устройств использует близкую к доступной полосе пропускания на своих локальных каналах ([A, C], [B, C], [F, G] и D, E]), предполагая, что все каналы имеют одинаковую скорость, канал [C, D] будет перегружен трафиком, превратившись в узкую точку в сети.
Когда канал перегружен, например канал [C, D] на рисунке ниже, по каналу будет отправлено больше трафика, чем пропускная способность канала. Во время перегрузки сетевое устройство, такое как маршрутизатор или коммутатор, должно определять, какой трафик следует перенаправить, какой отбросить и в каком порядке следует пересылать пакеты. Для решения этой проблемы были созданы различные схемы приоритезации.
Управление перегрузкой каналов путем приоритизации одних классов трафика над другими входит в широкий раздел качества обслуживания (QoS). Восприятие QoS среди сетевых инженеров вызывает беспокойство по многим причинам. Например, многие реализации, даже недавние, как правило, не так хорошо продуманы, как могли бы быть, особенно в том, как они настроены и поддерживаются. Кроме того, ранние схемы не всегда работали хорошо, и QoS часто может добавить проблем в сети, а не облегчить их, и, как правило, очень трудно устранить неполадки.
По этим причинам, а также из-за того, что конфигурация, необходимая для реализации схем приоритезации, имеет тенденцию к непостижимости, QoS часто считается темным искусством. Чтобы успешно реализовать стратегию QoS, вы должны классифицировать трафик, определить стратегию организации очередей для различных классов трафика и согласованно установить стратегию на всех сетевых устройствах, которые могут испытывать перегрузку каналов.
Хотя можно погрузиться во множество различных функций и функций схем и реализаций QoS, результат всегда должен быть одним и тем же.
Почему бы просто не сделать линии связи достаточно большими?
После обдумывания ценностного предложения QoS очевидной реакцией будет вопрос, почему сетевые инженеры просто не выбирают достаточно большие линии связи, чтобы избежать перегрузки. В конце концов, если бы линии связи были достаточно большими, перегрузка исчезла бы. Если перегрузка исчезнет, исчезнет необходимость отдавать приоритет одному типу трафика над другим. Весь трафик будет доставлен, и все эти досадные проблемы, связанные с недостаточной пропускной способностью, будут устранены. Действительно, избыточное выделение ресурсов, возможно, является лучшим QoS из всех.
К сожалению, стратегия избыточного обеспечения не всегда является доступным вариантом. Даже если бы это было так, самые большие доступные каналы связи не могут преодолеть определенные модели трафика. Некоторые приложения будут использовать столько пропускной способности, сколько доступно при передаче данных, создавая точку перегрузки для других приложений, совместно использующих линию связи. Другие будут передавать в микроперерывах, подавляющих сетевые ресурсы в течение короткого времени, и некоторые транспортные механизмы-такие как протокол управления передачей (TCP)-будут намеренно собирать путь время от времени, чтобы определить наилучшую скорость передачи данных. В то время как более крупная линия связи может сократить время существования состояния перегрузки, в некоторых сценариях нет такой вещи, как наличие достаточной полосы пропускания для удовлетворения всех требований.
Большинство сетей построены на модели избыточной подписки, когда некоторая совокупная пропускная способность распределяется в определенных узких местах. Например, коммутатор Top of Rack (ToR) в загруженном центре обработки данных может иметь 48 портов 10GbE, обращенных к хостам, но только 4 порта 40GbE, обращенных к остальной части центра обработки данных. Это приводит к коэффициенту переподписки 480:160, который уменьшается до 3:1. Неявно, 160 Гбит/с полосы пропускания центра обработки данных является потенциальным узким местом - точкой перегрузки - для 480 Гбит/с полосы пропускания хоста. И все же соотношение переподписки 3:1 является обычным явлением в схемах коммутации центров обработки данных. Зачем?
Окончательный ответ - часто деньги. Часто можно спроектировать сеть, в которой граничные порты соответствуют доступной пропускной способности. Например, в структуре центра обработки данных, приведенной выше, почти наверняка можно добавить достаточную пропускную способность канала, чтобы обеспечить 480 Гбит / с из ToR в структуру, но стоимость вполне может быть непомерно высокой. Сетевой инженер должен учитывать не только стоимость порта и оптоволокна, но и стоимость дополнительного питания, а также стоимость дополнительного охлаждения, необходимого для управления окружающей средой после добавления необходимых дополнительных устройств, и даже затраты дополнительного места в стойке и веса пола.
Затраты денег на обеспечение более высокой пропускной способности сети также могут быть трудно оправданы, если сеть редко перегружена. Некоторые события перегрузки не являются достаточно частыми, чтобы оправдать дорогостоящее обновление сети. Будет ли город тратить миллионы или миллиарды долларов на улучшение транспортной инфраструктуры, чтобы облегчить движение раз в год, когда политик приезжает с визитом? Нет. Вместо этого для решения проблемы с трафиком вносятся другие корректировки.
Например, компании могут наиболее остро столкнуться с этим ограничением в глобальных сетях, где каналы арендуются у поставщиков услуг (SP). Частично поставщики услуг зарабатывают деньги на объединении разрозненных географических регионов для организаций, которые не могут позволить себе прокладывать и использовать оптоволоконные кабели большой протяженности самостоятельно. Эти линии дальней связи обычно предлагают гораздо более низкую пропускную способность, чем более короткие, местные линии связи в одном кампусе или даже в одном здании. Высокоскоростное соединение в университетском городке или центре обработки данных может легко перегрузить более медленные каналы дальней связи.
Организации будут устанавливать максимально возможные размеры дальних (таких как межсайтовые или даже межконтинентальные) линий связи, но, опять же, важно помнить о деньгах.
В мире избыточной подписки и последующих точек перегруженности, а также временных моделей трафика, которые требуют тщательного управления, схемы приоритизации трафика QoS всегда будут необходимы.
Классификация
Схемы приоритизации QoS действуют на различные классы трафика, но что такое класс трафика и как он определяется?
Классы трафика представляют собой агрегированные группы трафика. Потоки данных из приложений, требующих аналогичной обработки или представляющих аналогичные схемы трафика в сети, помещаются в группы и управляются политикой QoS (или классом обслуживания, CoS). Эта группировка имеет решающее значение, поскольку было бы трудно определить уникальные политики QoS для потенциально бесконечного числа приложений. С практической точки зрения сетевые инженеры обычно группируют трафик в четыре класса. Конечно, возможны и другие классы, и такие схемы существуют в производственных сетях. Однако управление системой классификации и политическими действиями становится все более утомительным по мере того, как число классов превышает четыре.
Каждый пакет может быть отнесен к определенной CoS на основе адреса источника, адреса назначения, порта источника, порта назначения, размера пакета и других факторов. Предполагая, что каждое приложение имеет свой собственный профиль или набор характеристик, каждое приложение может быть помещено в определенный CoS и действовать в соответствии с локальной политикой QoS. Проблема с этим методом классификации трафика заключается в том, что классификация является только локально значимой-действие классификации относится только к устройству, выполняющему классификацию.
Такая классификация пакетов требует много времени, а обработка каждого пакета потребует больших вычислительных ресурсов. Поэтому лучше не повторять эту обработку на каждом устройстве, через которое проходит пакет. Вместо этого лучше один раз классифицировать трафик, пометить пакет в этой единственной точке и действовать в соответствии с этой маркировкой на каждом последующем переходе в сети.
Примечание: Несмотря на то, что пакеты и кадры в сети различны, в этой статье будет использоваться термин пакеты.
Были разработаны и стандартизированы различные схемы маркировки, такие как 8-битное поле типа обслуживания (ToS), включенное в заголовок Интернет-протокола версии 4 (IPv4). Версия 6 того же протокола (IPv6) включает 8-битовое поле класса трафика, служащее аналогичной цели. Кадры Ethernet используют 3-битное поле как часть спецификации 802.1p. На рисунке показано поле ToS IPv4.
В наилучшей сетевой практике классификация трафика должна приводить к одному действию и только к одному действию-маркировке. Когда пакет помечен, присвоенное значение может сохраняться и действовать на протяжении всего пути следования пакета по сетевому пути. Классификация и последующая маркировка должны быть "одноразовым" событием в жизни пакета.
Лучшая практика QoS - рекомендуется маркировать трафик, как близко к источнику, насколько это возможно. В идеале трафик будет помечен в точке входа в сеть. Например, трафик, поступающий в сетевой коммутатор с персонального компьютера, телефона, сервера, устройства Интернета вещей и т. д. будет помечена, и метка будет служить классификатором трафика на пути следования пакета по сети.
Альтернативная схема классификации и маркировки трафика входящим сетевым устройством заключается в том, что приложение само маркирует свой собственный трафик. Другими словами, пакет отправляется с уже заполненным байтом ToS. Это поднимает проблему доверия. Следует ли разрешить приложению ранжировать собственную важность? В худшем случае все приложения эгоистично помечают свои пакеты значениями, указывающими наивысшую возможную важность. Если каждый пакет помечен как очень важный, то на самом деле ни один пакет не является особо важным. Чтобы один пакет был более важным, чем любой другой, должна быть дифференциация. Классы трафика должны иметь разные уровни важности, чтобы схемы приоритезации QoS имели какое-либо значение.
Для сохранения контроля над классификацией трафика все сети, реализующие QoS, имеют границы доверия. Границы доверия позволяют сети избежать ситуации, когда все приложения помечают себя как важные. Представьте, что произошло бы на перегруженной дороге, если бы у каждого автомобиля были мигающие аварийные огни - действительно важные автомобили не выделялись бы.
В сети некоторым приложениям и устройствам доверяют отмечать свой собственный трафик. Например, IP-телефонам обычно доверяют соответствующим образом маркировать свой потоковый голосовой трафик и трафик протокола управления, то есть метки, которые IP-телефоны применяют к своему трафику, принимаются входным сетевым устройством. Другие конечные точки или приложения могут быть ненадежными, что означает, что байт ToS пакета стирается или перезаписывается при входе. По умолчанию большинство сетевых коммутаторов стирают метки, отправленные им, если они не настроены на доверие определенным устройствам. Например, производителям, помещенным в пакет сервером, часто доверяют, а маркировкам, установленным конечным хостом, - нет. На рисунке ниже показана граница доверия.
На рисунке 3 пакеты, передаваемые B, помечены AF41. Поскольку эти пакеты исходят от хоста в домене доверия QoS, маркировка остается, пока они проходят через D. Пакеты, исходящие от A, помечаются EF; однако, поскольку A находится за пределами доверенного домена QoS, эта маркировка удаляется в D. Пакеты в пределах доверенного домена, исходящие из A, рассматриваются как немаркированные с точки зрения QoS. Маркировка протокола физического уровня и верхнего уровня может быть связана, а может и не быть. Например, маркировка верхнего уровня может быть скопирована в маркировку нижнего уровня, или маркировка нижнего уровня может быть перенесена через сеть, или маркировка нижнего уровня может быть удалена. Существует множество различных возможных реализаций, поэтому вы должны быть осторожны, чтобы понять, как маркировка обрабатывается на разных уровнях, а также на каждом переходе.
Хотя операторы сети могут использовать любые значения, которые они выбирают в байте ToS для создания различных классов трафика, часто лучше придерживаться некоторых стандартов, таких как значения, определенные стандартами IETF RFC. Эти стандарты были определены для того, чтобы дать сетевым инженерам логическую схему, позволяющую надлежащим образом различать множество различных классов трафика.
Две из этих схем "Per Hop Behavior" появляются в RFC2597, Assured Forwarding (AF), и RFC3246, Expedited Forwarding (EF), а также в различных других RFC, обновляющих или уточняющих содержание этих основополагающих документов. Оба эти RFC определяют схемы маркировки трафика, включая точные значения битов, которые должны заполнять байт ToS или байт класса трафика IP-заголовка, чтобы указать конкретный тип трафика. Они известны как точки кода дифференцированного обслуживания или значения DSCP.
Например, схема гарантированной пересылки RFC2597 определяет 12 значений в побитовой иерархической схеме для заполнения восьми битов в поле байта ToS. Первые три бита используются для идентификации класса, а вторые три бита определяют приоритет отбрасывания. Последние два бита не используются. Таблица 1 иллюстрирует маркировку кода для нескольких классов AF.
В таблице 1 показано значение бита DSCP для AF11, трафика класса 1 с низким приоритетом отбрасывания, равным 001 010, где "001" обозначает класс 1, а "010" обозначает приоритет отбрасывания. Изучение таблицы более глубоко раскрывает бинарный паттерн, выбранный авторами RFC. Весь трафик класса 1 помечается 001 в первых трех битах, весь класс 2-010 в первых трех битах и т. д. Весь трафик с низким приоритетом отбрасывания помечается 010 во-вторых трех битах, весь трафик со средним приоритетом отбрасывания-100 во-вторых трех битах и т. д.
Схема гарантированной пересылки показана в таблице 2 для примера. Это не исчерпывающий список кодовых точек, используемых при классификации трафика QoS. Например, схема выбора класса, описанная в RFC2474, существует для обратной совместимости со схемой маркировки приоритета IP. Приоритет IP использует только первые три бита байта ToS, всего восемь возможных классов. Селектор классов также использует восемь значений, заполняя первые три бита шестибитового поля DSCP значимыми значениями (соответствующими устаревшей схеме приоритета IP), а последние три бита - нулями. В таблице 2 показаны эти селекторы классов.
RFC3246 определяет требования к задержке, потерям и джиттеру трафика, который должен быть перенаправлен быстро, вместе с единственной новой кодовой точкой - EF, которой присвоено двоичное значение 101 110 (десятичное 46).
Количество и разнообразие формально определенных значений DSCP может показаться ошеломляющим. Комбинированные определения AF, CS и EF сами по себе приводят к формальным определениям для 21 различных классов из возможных 64, использующих шесть битов поля DSCP. Ожидается ли, что сетевые инженеры будут использовать все эти значения в своих схемах приоритезации QoS? Следует ли разбивать трафик с такой высокой степенью детализации для эффективного QoS?
На практике большинство схем QoS ограничиваются от четырех до восьми классов трафика. Различные классы позволяют обрабатывать каждую группу по-своему во время перегрузки. Например, один класс трафика может быть сформирован так, чтобы соответствовать определенному порогу пропускной способности. Другой класс трафика может иметь приоритет над всем остальным трафиком. Еще один может быть определен как критически важный для бизнеса или трафик, который важнее большинства, но менее важен, чем некоторые. Трафик сетевого протокола, критичный для стабильности инфраструктуры, можно рассматривать как очень высокий приоритет. Класс трафика scavenger может находиться в конце списка приоритетов, получая немного больше внимания, чем немаркированный трафик.
Схема, включающая эти значения, вероятно, будет представлять собой сочетание кодовых точек, определенных в различных RFC, и может несколько отличаться от организации к организации. Обычно принятые значения включают EF для критического трафика с требованием своевременности, например VoIP, и CS6 для трафика управления сетью, такого как протоколы маршрутизации и резервирования на первом этапе. Немаркированный трафик (т.е. значение DSCP, равное 0) доставляется по принципу "максимальных усилий", без каких-либо гарантий уровня обслуживания (обычно это считается классом scavenger, как указано выше).
Привет, друг! В этой статье мы расскажем про подключение Third Party SIP телефонов (то есть телефонов и софтфонов от других вендоров, поддерживающих RFC3261) к Cisco Unified Communications Manager (CUCM) . В качестве примера будем подключать популярный и бесплатный софтфон X-Lite.
Настройка Cisco Unified Communications Manager
Первым делом создадим пользователя в CUCM. Для этого переходим во вкладку User Management → End User.
Здесь указываем следующую информацию:
User ID
Password (не используется в X-Lite, но необходимо указать при создании пользователя)
PIN (также не используется в X-Lite)
Last Name
Digest Credentials (это поле используется как пароль в X-Lite)
Затем добавляем SIP Phone. Для этого переходим во вкладку Device – Phone и нажимаем Add. Здесь в поле Phone Type выбираем Third-party SIP Device. Basic поддерживает одну линию, Advanced поддерживает до восьми линий.
Далее нужно заполнить следующие поля:
MAC Address – нужно указать уникальный адрес, для X-Lite можно указать любой, т.к не используемся для авторизации;
Device Pool – можно указать стандартный Default;
Phone Button Template – Third-party SIP Device;
Security Device Profile – стандартный профиль Third-party SIP Device;
SIP Profile – Standard SIP Profile;
Owner User ID и Digest User – End User которого мы создавали ранее;
После этого нажимаем Save и переходим в окно настроек телефона. Здесь нажимаем Line [1] – Add a new DN и в поле Directory Number указываем номер, который будем использовать. После этого возвращаемся во вкладку User Management → End User, находим созданного пользователя, и проверяем находиться ли SIP Phone в Controlled Devices. Если нет, то нажимаем Device Association, и тут выбираем добавленный нами SIP Phone, после чего он должен появиться в поле Controlled Devices.
Настройка софтфона
Открываем программу X-Lite, переходим в меню Account Settings.
Тут заполняем следующие поля:
Display Name – указываем желаемое имя, которое будет отображаться в программе;
User Name – указываем Directory Number (DN) в CUCM;
Password – Digest Credentials в CUCM;
Authorization user name – User ID в CUCM;
Domain – адрес сервера CUCM;
После этого нажимаем OK и наш софтфон должен зарегистрироваться.
Средства безопасности, оркестровки, автоматизации и реагирования (SOAR - Security Orchestration, Automation and Response) - это программные продукты, которые позволяют ИТ-группам определять, стандартизировать и автоматизировать действия организации по реагированию на инциденты. Большинство организаций используют эти средства для автоматизации операций и процессов обеспечения безопасности, реагирования на инциденты и управления уязвимостями и угрозами.
Как правило, решения SOAR позволяют группам собирать ценные данные по безопасности, выявлять, анализировать и устранять существующие и потенциальные угрозы и уязвимости из различных источников. Следовательно, эти инструменты обеспечивают большую видимость, что позволяет организациям быстрее, эффективно и последовательно реагировать на инциденты, связанные с безопасностью.
Идеальный инструмент SOAR должен:
Прием и анализ информации и уведомлений из различных систем безопасности.
Возможность определять, создавать и автоматизировать рабочие процессы, необходимые группам для определения приоритетов, изучения и реагирования на предупреждения безопасности.
Управление и интеграция с широким спектром инструментов для улучшения операций.
Наличие возможностей экспертизы для проведения послеаварийного анализа и предоставления группам возможности совершенствовать свои процессы и предотвращать подобные проблемы.
Автоматизирует большинство операций по обеспечению безопасности, устраняя повторяющиеся задачи и позволяя командам экономить время и концентрироваться на более сложных задачах, требующих вмешательства человека
Такие инструменты работают на основе искусственного интеллекта, машинного обучения и других технологиях для автоматизации повторяющихся задач, таких как сбор информации, обогащение и корреляция данных и многое другое. Такой подход помогает командам быстрее и масштабно реагировать на широкий круг вопросов безопасности.
Кроме того, в большинстве решений SOAR имеются плейбуки, содержащие инструкции, основанные на проверенных практиках и процедурах. Использование плейбуков обеспечивает согласованность, соответствие нормативам, более быструю и надежную идентификацию и устранение инцидентов.
В настоящее время, на рынке много продуктов для обеспечения безопасности. В данном материале составили список лучших решений SOAR, чтобы помочь вам выбрать подходящее решение для удовлетворения ваших уникальных потребностей.
Давайте рассмотрим их.
1. Splunk Phantom
Splunk Phantom - это решение SOAR, которое интегрируется с широким спектром средств безопасности, чтобы дать командам лучшее представление и возможность обнаруживать внутренние и внешние угрозы и реагировать на них. Он поставляется с визуальным редактором плейбуков (VPE - Visual Playbook Editor), который позволяет специалистам по безопасности и разработчикам использовать встроенную функцию перетаскивания для создания комплексных плейбуков.
Ключевые особенности
Разработка пользовательских процессов автоматизации для определенных рабочих процессов.
Фильтрация данных и определение настраиваемых действий безопасности
Позволяет командам сотрудничать и принимать критически важные решения по безопасности в режиме реального времени.
Быстрое решение SOAR для повышения безопасности в организации и быстрого устранения инцидентов
Централизованная визуализация
Функция «События в день» (EPD), показывающая события безопасности, управляемые средством.
2. IBM Resilent
IBM Resilient - платформа SOAR на основе машинного обучения с расширенными возможностями обнаружения угроз и реагирования на инциденты. Решение SOAR доступно для локальной установки, как служба MSSP (Managed Security Service Provider) или как модель развертывания Security as a Service (SaaS). Она предоставляет командам единую платформу и возможность автоматизировать операции, вести расследование, улучшать совместную работу и устранять угрозы быстрее и эффективнее.
Ключевые особенности
Позволяет командам получать доступ к подробному расследованию угроз и предупредительным сигналам безопасности, что позволяет быстро реагировать на любые инциденты и управлять ими.
Гибкие возможности развертывания, автоматизации и оркестровки для удовлетворения уникальных бизнес-потребностей
Получать информацию о происшествиях, связанных с безопасностью, понимать их и определять их приоритеты, а затем принимать соответствующие меры по исправлению положения.
Встроенная функция моделирования кибератак для проверки систем безопасности и достоверности плейбуков. Эта функция помогает группам выполнять аудит соответствия требованиям.
Динамичные и аддитивные учебники для предоставления командам соответствующих знаний и рекомендаций по эффективному урегулированию инцидентов, связанных с безопасностью.
3. DFLabs IncMan
DFLabs IncMac - это многофункциональная, гибкая и масштабируемая платформа SOAR, которая помогает организациям повысить уровень безопасности и автоматизации. Веб-платформа или платформа SaaS подходит для MSSP, CSIRT, SOC и других для автоматизации, измерения и управления процессами реагирования на инциденты и другими операциями по обеспечению безопасности.
Единый интуитивно понятный инструмент на базе ИИ упрощает обнаружение и управление широким спектром инцидентов, связанных с безопасностью.
Ключевые функции
Интегрируется с другими средствами безопасности, что обеспечивает бесперебойную работу и обмен полезной информацией между различными группами реагирования.
Подробные отчеты в виде графиков, настраиваемые KPI и выполнение корректировок. Эта информация позволяет различным заинтересованным сторонам оценивать эффективность своих усилий.
Полное комплексное управление инцидентами на основе машинного обучения и передовых технологий поиска угроз - включает в себя управление расследованиями, отчетность по инцидентам, заметки для аудита, корректирующие и профилактические действия (CAPA), отказоустойчивость и многое другое.
Обеспечивает быстрое обнаружение инцидентов, реагирование, исправление и возможность определения приоритетов ответов на основе различных триггеров.
Автоматизирует расследования угроз безопасности, поиск угроз и сбор данных по инциденту.
4. Insightconnect
Rapid7 Insightconnect - это SOAR решение, которое интегрирует, оптимизирует и ускоряет процессы безопасности с минимальным написание кода или вообще без него. Платформа объединяет средства безопасности и команды для обеспечения полной интеграции и четкой коммуникации между различными технологиями.
Ключевые особенности
Обнаружение, блокировка и реагирование на атаки, вредоносные программы, фишинговые атаки, скомпрометированные учетные записи пользователей, уязвимые сетевые порты и т.д.
Автоматизация поиска угроз и других процессов для быстрой идентификации вредоносных программ, зараженных URL-адресов и доменов, а также подозрительных действий.
Автоматизация обнаружения, блокировки и расследование вирусов, вредоносных программ и фишинговых атак по электронной почте, а также других вредоносных программ
Обеспечивает видимость в реальном времени и способность быстрее и умнее реагировать на инциденты, связанные с безопасностью
Поддержка автоматический запуск плейбуков для ускорения реагирования на инциденты.
5. RespondX
LogRhythm RespondX - это простое решение SOAR, которое обеспечивает надежное обнаружение угроз в режиме реального времени и позволяет организациям повысить уровень безопасности. Функция SmartResponse помогает автоматизировать рабочие процессы и ускорить процессы расследования угроз и реагирования на них.
Ключевые особенности
Комплексное средство, поддерживающее сквозные процессы реагирования на инциденты безопасности от сбора данных и карантина конечных точек, до блокирования скомпрометированных сетевых ресурсов и портов.
Автоматизация процессов реагирования на инциденты для эффективного снижения всех рисков, выявления и устранения уязвимостей для предотвращения подобных атак в будущем.
Выявление последствий и восстановление при расследовании инцидента
Интерфейс пользователя, который может обновлять обращения, включая данные журнала, предупреждения и другую информацию.
Автоматическое приостановление рискованных или скомпрометированных учетных записей пользователей, процессов и сетевого доступа.
6. Exabeam
Средство реагирования на инциденты Exabeam - это мощная, экономичная, быстрая и безопасная платформа для обнаружения, расследования и реагирования на угрозы безопасности. Простое в использовании автоматизированное средство с простым пользовательским интерфейсом устраняет ручные расследования и задачи по смягчению последствий, предоставляя решение для борьбы с угрозами, распределенными атаками и т. д.
Ключевые особенности
Предоставляет единую простую в использовании платформу управления безопасностью, которая не требует высокого уровня экспертных знаний
Простой в использовании и быстрый поиск по массиву данных
Расширенное комплексное обнаружение инцидентов как для внутренних, так и для внешних угроз.
Готовые, настраиваемые и автоматизированные устройства воспроизведения инцидентов для оптимизации и стандартизации методов и процедур реагирования для обеспечения быстрых и повторяющихся действий без ошибок.
Предоставляет встроенные инструменты, оценки базового поведения или временной шкалы пользователя и показать предупреждение или потребовать дальнейшего вмешательства, когда оценка достигнет указанного порога.
7. ServiceNow
ServiceNow Security Operations - это мощное корпоративное решение для управления инцидентами и уязвимостями, а также для повышения интеллекта угроз безопасности и соответствия конфигурации. Как правило, инструмент SOAR позволяет анализировать, выявлять, устранять атаки и угрозы и восстанавливать после атаки. Таким образом, она предоставляет комплексное решение для управления полным жизненным циклом инцидентов безопасности.
Ключевые особенности
Автоматизация средств безопасности, процессов и действий, а также инструментов
Сводка уязвимостей, позволяющая командам своевременно выявлять и устранять слабые места и предотвращать атаки.
Предоставляет информацию о последних инцидентах и уязвимостях, связанных с безопасностью, вместе с соответствующими бизнес-процессами.
Позволяет быстрее выявлять, расставлять приоритеты и реагировать на инциденты, связанные с безопасностью, уязвимости, неправильно настроенные активы и другие риски.
Позволяет понять состояние безопасности, узкие места и тенденции с помощью аналитических отчетов и панелей мониторинга.
8. SIRP
SIRP - это надежное, универсальное решение SOAR, которое интегрируется с большинством готовых технологий и функций безопасности и предоставляет командам единую точку управления, автоматизацию, полную видимость и платформу управления инцидентами. Решение для обеспечения безопасности собирает данные из нескольких различных источников по всей инфраструктуре.
Затем он обогащает данные расследованием угроз и их анализом, после чего упорядочивает их по уязвимостям, инцидентам и другим классификациям для облегчения понимания и реагирования.
Ключевые особенности
Предоставляет ценные данные и улучшенную видимость по безопасности
Назначает оценку безопасности каждому инциденту, уязвимости и оповещает сотрудника, что позволяет группам расставлять приоритеты.
Интеграция с более чем 70 средствами безопасности и возможность выполнения более 350 действий с одной платформы
Обеспечивает полную видимость состояния безопасности систем с помощью интуитивно понятной панели мониторинга, подробных отчетов и аудитов инцидентов
Простой автоматизированный плейбук помогает методом перетаскивания упростить рабочие процессы и обеспечить эффективное реагирование на инциденты на основе проверенных процессов.
Заключение
Средства безопасности, управления, автоматизации и реагирования помогают оптимизировать управление уязвимостями, а процессы реагирования на угрозы повышают эффективность, сокращают время разрешения проблем и экономят средства.
Хотя существует много решений SOAR, они, вероятно, не решают все проблемы безопасности, с которыми сталкиваются компании. Поэтому при поиске решения обратите внимание на основные функции, которые наиболее важны для вашей организации, и выберите те из них, которые наилучшим образом соответствуют вашим требованиям.