Заглянуть в будущее

Многие подходы к ИБ заимствованы из военной науки, поэтому, повторяя принцип необходимости уничтожения противника на дальних подступах, мы пытаемся предотвратить компрометацию, причём, как можно раньше. В современных условиях это невозможно, по крайней мере, нерационально с точки зрения затрат на получаемый результат. Но это и не требуется, поскольку задача безопасности - не предотвратить взлом, а предотвратить ущерб, поэтому допустимо и, в современных условиях мудрее, полагать свою сеть уже взломанной, и уже из этого предположения планировать контроли безопасности. Очевидно, приоритет в этом случае будет отдан обнаружению, расследованию, реагированию и восстановлению после инцидента.

Подходу assume breach есть постнейшее логическое объяснение: если атака целевая (мы никогда ранее ее не видели), то при достаточно хорошей подготовке, обнаружить ее можно только когда ее активность начнет приводить к ущербу, а пока ущерба нет, собственно, и "придраться" не к чему - действия вполне себе легитимны. Начитанные могут возразить, мол, как же профилирование и машинное обучение без учителя..., однако, к сожалению, в реальной практике всякие UEBA работают не так хорошо, как хотелось бы. В большинстве сценариев обнаружения мы пытаемся максимально рано распознать риск нанесения ущерба, поэтому иногда мы интерпретируем легитимную деятельность, как имеющую под собой риск ущерба, и получаем ложные срабатывания, а иногда, к сожалению, не замечаем риск, не отличаем действия злоумышленника от легитимной активности, или делаем это слишком поздно, и получаем пропуск атаки.

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

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

Обнаружение именно по ущербу всегда с нами и в реальной жизни. В замечательном советском художественном фильме Александра Митты "Сказ про то, как царь Петр арапа женил" есть эпизод с ряжеными, где главный герой распознал недобрые намерения именно когда налицо был ущерб. Если бы у героя Владимира Высоцкого, да и у нас с вами, была возможность заглянуть в будущее и увидеть последствия текущей активности и наших действий по отношению к ней, мы бы увидели ущерб, и имели бы возможность на ранних этапах его не допустить. 

Несмотря на всю свою очевидность того, что я здесь описываю, мы часто сталкиваемся с «проверками», когда заказчик пишет кастомную утилитку и, используя ее у себя в сети, ожидает, что наш сервис MDR зарегистрирует ему инцидент, приводя «железобетоннные» аргументы, что в его действиях есть техники MITRE ATT&CK и только на этом основании мы должны регистрировать инцидент… В таких случаях мы отвечаем нейтрально, мол, упомянутая вами утилитка не является вредоносной, а действия с ней не свидетельствуют об атаке… По факту, мы не видим риска ущерба, тем более не видим ущерба, когда риск равен 100%, и поэтому не регистрируем инцидент.