В R-Vision SGRC появилась возможность управления операционными рисками

В R-Vision SGRC появилась возможность управления операционными рисками

В R-Vision SGRC появилась возможность управления операционными рисками

R-Vision сообщила о расширении функциональности системы R-Vision SGRC. В обновлённой версии добавлены новые инструменты для управления рисками информационной безопасности и операционными рисками в целом. Новый функционал ориентирован прежде всего на организации с высокой регуляторной нагрузкой — банки, страховые и другие финансовые компании.

Для них управление рисками напрямую связано с устойчивостью бизнеса и выполнением требований регуляторов. Впервые обновлённую версию продукта представят на Уральском форуме «Кибербезопасность в финансах».

В основе изменений — подход, при котором каждый риск рассматривается как отдельный объект со своим жизненным циклом. Он фиксируется в момент выявления и обрабатывается индивидуально: с собственным воркфлоу, ответственными и сроками.

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

При анализе система автоматически дополняет данные бизнес-контекстом, доступным в организации. Например, учитывается ценность актива и его роль в бизнес-процессах. Это реализовано через интеграции со смежными информационными системами и должно помочь более точно оценивать приоритеты.

Для упрощения запуска предусмотрены преднастроенный воркфлоу и типовая методика оценки операционных рисков, разработанная R-Vision. При необходимости её можно адаптировать под требования конкретной компании или создать собственную методику с помощью встроенного конструктора.

По сути, с расширением функциональности R-Vision SGRC выходит за рамки исключительно ИБ-рисков и становится инструментом для комплексного управления рисками на уровне всей организации.

В HoneyCorn нашли способ устранить недостатки IoC

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

Методы атак развиваются быстрее, чем инструменты защиты. Ускоряется разработка эксплойтов, упрощается развёртывание атакующей инфраструктуры, сокращается время её жизни и растёт уровень маскировки.

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

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

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

Давайте разберём почему.

  1. В классическом TI не собираются необходимые индикаторы компрометации в требуемом виде (базы паролей, используемых при брутфорсе, полные параметры фишинговых писем, семплы файлов, а также YARA-правила и хеши для инжектов и т. д.).
  2. Нет быстрой верификации индикаторов компрометации, в связи с этим — большое количество ложных срабатываний.
  3. Нет общепринятой классификации индикаторов компрометации по целевым спискам для решения всех необходимых задач и тюнинга количества ложных срабатываний.
  4. Нет единой унифицированной шины распространения индикаторов компрометации.
  5. Нет профессионального сообщества, обмена индикаторами компрометации для повышения базы сбора.
  6. Сейчас нет действенных механизмов сбора новых индикаторов без взлома реальных заказчиков.
  7. Не происходит автоматический реверс угроз нулевого дня.

И это только вершина айсберга – крутая технология становится посредственной из-за ряда практических недочётов.

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

RSS: Новости на портале Anti-Malware.ru