Мониторинг мошенничества
Мониторинг мошенничества на Iroha развертывание - это операционный контроль, основанный на событиях в регистре, запросах, разрешениях и контексте приложений. Iroha Система мониторинга определяет, какие модели являются подозрительными для Ваш бизнес-процесс и направление этих случаев к рецензентам или автоматизированным контролям ответа.
Мониторинг мошенничества следует рассматривать как отдельную услугу, а не логику, встроенную в валидатор. Услуга должна подписываться на деятельность бухгалтерского учета, обогащать ее контекстом рисков вне цепочки, сохранять доказательства и предоставлять ответные операции только через счета, имеющие явные разрешения.
Модель мониторинга
Полезный мониторинг состоит из четырех этапов:
- Собирать сигналы бухгалтерского учета и оператора из потоков событий Torii, запросов и показателей.
- События обогащаются контекстом вне цепочки, таким как статус клиента, списки контрагентов, идентификаторы сеансов заявки, ожидаемые пределы и случай IDs.
- Выявление подозрительного поведения с помощью детерминистических правил, очередь рецензентов или оценки риска.
- Отвечайте, предупреждая операторов, приостанавливая рабочие процессы на стороне приложений, отзывы ненужных разрешений или предоставляя компенсационные транзакции, когда ваш процесс управления позволяет.
Сохранять политические решения вне консенсуса, если только каждый validator не должен повторять одно и то же решение. Валидация времени запуска должна обеспечивать соблюдение разрешений и действия транзакции. Наблюдение за мошенничеством должно объяснять риск, сохранять доказательства и помогать операторам быстро действовать.
Сигналы для сбора
Начните с узких подписок и добавьте более широкие потоки только для расследования:
| Сигнал . | Источник | Использовать |
|---|---|---|
| Статус сделки | События в трубопроводе | Выявление неоднократных отказов, неудачных попыток выдачи разрешений и необычных моделей подачи заявки |
| жизненный цикл счета и метаданные | События с данными и запросы счетов | Выявление новых учетных записей, изменений псевдонимов, обновлений личности и неожиданных редактирования метаданных |
| Сальдо активов и переводы | События по данным активов и запросы на активы | Выявление высококачественных движений, быстрого вытягивания вентилятора, балансовых канализаций и необычных контрагентов |
| Роли и разрешения | Запросы по роли и разрешениям, события с данными о роли | Выявить эскалацию привилегий, аварийные гранты и устаревший доступ с высоким риском |
| Изменения триггера и контракта | Возбуждение, контракт и исполнение событий | Выявление новой автоматизации, изменение путей выполнения и подозрительная активность обновления |
| Конфигурация и изменения сверстников | Конфигурация и события сверстников | Выявление изменений в управленческом режиме , которые влияют на валидацию , сеть или видимость оператора |
| Здоровье оператора | маршруты статуса /metrics и Sumeragi | Отделить подозрительное поведение пользователя от перегрузки узлов, давления в очереди или ошибок сети. |
Используйте фильтры событий , чтобы избежать обработки всего потока событий, когда правило требует только учетных записей, активов, ролей или изменений конфигурации. Для периодической совместимости, объединяйте поток с страничными запросами , чтобы монитор мог восстановиться после перебоев.
Правила обнаружения
Общие правила включают в себя:
| Семья правил | Примерное условие | Типичный ответ |
|---|---|---|
| Скорость | Счет перечисляет больше , чем ожидается в течение короткого периода времени | Предусмотрщики предупреждения и пауза снятия заявок на данный счет |
| Распространение | Средства перемещаются с одного счета на несколько новых счетов | Требуется руководство к одобрению , прежде чем разрешить дополнительные переводы |
| Вывод баланса | Большая доля баланса счета уходит вскоре после изменения ключа, псевдоним или метаданных. | Эскалация как можно большего объема аккаунтов |
| Эскалация привилегий | Высокорисковое разрешение или роль предоставляется за пределами окна изменения | Предупреждение операторов и пересмотр транзакции гранта |
| Прорыв отказов | Один подписывающийся или клиент совершает неоднократно отклоняемые сделки | Проверьте злоупотребление удостоверениями личности, ошибки в интеграции или проверку. |
| Изменение автоматизации | Отрицатель , контракт или объект , связанный с исполнением , неожиданно меняется | Приостанавливать зависимые рабочие процессы , пока изменение не будет рассмотрено |
| Смены , связанные с управлением | Изменения соотношения, конфигурации или состояния времени выполнения происходят без утвержденного билета | Сравните с отчетом о управлении и процессом инцидентов |
Правила должны быть ясными относительно доказательств, которые они требуют, времени, которое они оценивают, действий, которые они предпринимают, и человека или системы, которая может закрыть дело. Предел, который зависит от риска клиента, типа активов или юрисдикции, относится к конфигурации службы мониторинга, а не к специальным сценариям.
Контроль ответа
Проектировать действия реагирования до включения сигналов. Дело о мошенничестве высокой степени тяжести должно иметь задокументированный путь от выявления до пресечения:
- уведомляет владельцев ценных бумаг, операций и предприятий, ответственных за определение затрагиваемого домена или актива;
- сохранить курсор событий, хэш блокировки, хэш транзакции, авторитет, полезную нагрузку и снимок запроса, используемый правилом обнаружения
- приостановка действий со стороны приложений, которые находятся за пределами бухгалтерского учета, таких как процессы выписки, снятия заявки, подписания, моста или расчетов;
- аннулировать роли или разрешения, которые больше не обоснованы планом реагирования на инциденты;
- представлять последующие операции в регистре только тогда, когда политика активного управления и модель разрешений позволяют их осуществлять
- Переключивать ключи, когда доказательства указывают на компромисс подписанта
Избегайте предоставления сервису мониторинга широкого доступа к записи. Используйте специальный технический аккаунт с наименьшим набором разрешений, необходимых для выполнения ответных действий. Утверждение человеком должно оставаться частью любого рабочего процесса, который может перемещать активы, изменять разрешения или изменить конфигурацию, ориентированную на валидатора.
Доказательства и сохранение
Сохранить доказательства мониторинга в системе только приложений, отдельной от справочника данных валидатора.
- название потока событий и курсор
- высота блока или хэш блока, когда они доступны
- транзакционный хэш и авторитет
- затрагиваемый счет, домен, актив, роль, триггер или конфигурация ID
- необработанная полезная нагрузка событий или канонический хэш ее
- Сноуки запроса , используемые для обогащения оповещения
- название правила, версия, порог, балл и решение рецензента
Не храните конфиденциальные расследовательские записки в качестве метаданных публичной книги, если политика управления данными сети не позволяет. Если вам нужно связать случай вне цепи с состоянием на цепи, предпочтительно идентификатор случая, подписанное удостоверение или хэш-завет, который не раскрывает частные данные.
Перечень выполнения
- Включить профиль телеметрии, необходимый для маршрутов
/metricsи оператора. - Подпишитесь на потоки событий Torii с узкими фильтрами для объектов, которые вы контролируете.
- Продолжайте курсоры событий, чтобы монитор мог возобновить работу без пробелов.
- Согласите потоки с страничными запросами на регулярный график.
- Сохранить пороги риска и разрешить перечень в конфигурации с управляемой версией.
- Правила проверки сигнализации против исторических блоков перед включением автоматизированных действий.
- Используйте специальные технические отчеты для ответных действий.
- Предусмотр роли и разрешений предоставляется по периодическому графику.
- Включить в процесс реагирования на инциденты предупреждения о мошенничестве.