Это позволяет чётко объяснить бизнесу, что и как вы защищаете. Не абстракные хосты и приложения. А процессы и связанные с ними ресурсы

То есть теперь DLP и UEBA вам нужно не для того, чтобы подглядывать за сотрудниками, а SIEM - не для отчётности кому-то, а всё это станет нужно для защиты процессов, а значит - денег.

Так, на вопрос "почему" мы ответили 🙂

Теперь как

Сначала, sorry to say it, надо понять, как работает ваша компания. Не как серваки стоят, не как трафик маршрутизируется, не как права выдаются, а что и зачем делает ваша организация. Как из ресурсов на входе получается результат на выходе.

В каждой компании есть сотня-другая бизнес-процессов. У каждого бизнес-процесса есть владелец. Например, HR заведает кадровыми процессами - найм, увольнение, карьерный рост, каждый можно разбить на подпроцессы типа "тестирование", "аттестация", "обучение" и т.п. Финансы - платежи, управление средствами (декомпозируйте сами). Бухгалтерия - начисление зарплаты, надбавок, премий, сдача отчётности и т.п. Я специально пишу "горизонтальные" процессы, поскольку специфические отраслевые процессы в каждой отрасли свои, а я не совсем в курсе, кто меня читает

Есть целая наука BPM (business process management) и куча софта для этого. Почитайте основы, это не сложно. Процесс это алгоритм с теми же копмонентами: действия, результат, точки ветвления, ветки, циклы и т.п.

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

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

+1

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

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

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

Дальше выделяем эталон и допустимые отклонения (в терминах статистики - матожидание и дисперсию) по каждому этапу процесса и начинаем "резать" отклонения

Давайте пример.

Есть служба доставки. Грубо процесс такой: получает в свою ИТ-систему заказы на доставку (из колл-центра, выгрузки из системы корпоративного клиента, почтой, через форму на сайте и т.п.), заказывает товар на склад (система документооборота или e-mail), оформляет документы (1C), высылает курьера c онлайн-кассой (платёжный софт), получает деньги (ДБО), делает документы (1С),  закрывает сделку. Как вы видите, в процессе участвует десяток приложений

Есть сбои (или атаки, в такой постановке задачи разницы нет), которые могут привести к неудаче единицы процесса (ложный вызов, не тот товар, не те документы) - то есть курьер съездит, но заявка не будет выполнена. Это прямой убыток

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

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

У плохого события есть свой "killchain" - последовательность аномальных событий, приводящих к неудаче. Их мы статистически и определяем. Это даёт нам возможность предсказывать неудачи единицы процесса на ранней стадии