Подводка ведущего
Ну, как мы уже сегодня все поняли, иногда просто самый файл, какой-то один большой, может оказаться чем-то другим, чем он является на самом деле. То есть, например, какая-нибудь фотография с отпуска, она может хранить себе не только пальмы, но и, например, Excel-файл. Это и называется стеганография, о которой нам сегодня, в принципе, и расскажет Алексей Дрозд. Представитель компании «СёрчИнформ». Давайте поддержим его аплодисментами и посмотрим, что же все-таки у нас есть.
Доклад и вопросы
Всем здравствуйте. Я тут ненадолго лишь, оказывается, выпустил микрофон из рук. Я хотел переделать доклад, но было поздно. Переделать в каком ключе? Отсылку дать. Кто был в прошлом году или помнит прошлогодний доклад, я про методологию рассказывал, про линию жизни инцидента. Так вот, при чем тут стеганография? Я ее рассматриваю с одной стороны здесь, хотя сами пользователи тоже тяготеют к использованию стеганографии в плане выноса информации, но чаще все-таки из-за того, что нельзя поставить любой софт или же стеганография
— это все-таки не для средних умов, чтобы самому такой движок написать, продвинувшись дальше, чем copy /b и склейки файлов. Вот, то пользователи все-таки больше пока отдают предпочтение криптографии, но в плане очень примитивной кодирования, то есть атакуя то, что не могут DLP-системы, например, или прочие системы контроля распознать. Самое банальное, чего ждут аналитики чуть ли не всего мира, это то, что придут большие языковые модели, в том числе LLM, и порешают вот такой примитив. Пользователь, вынося какие-нибудь перс-данные, берет Ctrl+F, найти, заменить, и заменяет какую-нибудь цифру 5 буквами «пять». То есть и у нас все перс-данные, которые раньше состояли из, допустим, цифр и отлично ловились регулярными выражениями, теперь там не очень ловятся регулярными выражениями. И есть 100500 способов, как в принципе придумать трюк, который не раскусит ни одна из известных мне DLP-систем без помощи каких-нибудь нейронок и так далее.
Так вот, а стеганография в том числе нужна и безопаснику. Для чего она ему нужна? Так, ага, все, теперь я понимаю, почему народ не туда переключался. Вот он, UI/UX интерфейс. Верхняя кнопка переключает назад, а нижняя кнопка переключает вперед. Вот, знаете это. Так вот, зачем стеганография безопаснику нужна сама по себе? Для того, чтобы как раз таки подстелить соломку. Если вы узнаете или вспомните линию жизни инцидента, что это такое? Это временная шкала, есть на ней точка невозврата, когда совершилась утечка, когда вынесли информацию. Мы, как бывшие уже владельцы, не знаем, что с ней делают, как ее модифицируют, куда ее распространяют, кто к ней имеет доступ. Так вот, инцидент уже случился.
Это порождает в умах отдела безопасности стадию жесткого ощущения приближающегося апокалипсиса, это научный термин, а не научный, те самые 24 часа на реагирование, 72 часа на то, чтобы кому-то чего-то рассказать и так далее. И, получается, наступает та самая фаза, где надо расследовать с одной стороны, что мы умеем, но с другой стороны полезно безопаснику помочь найти ту самую точку, с которой копать, хоть как-то сузить круг. Вот. Как это обычно происходит? Обычно безопасник, что он может делать? Чаще всего, используя те или иные инструменты, я это обозвал, использует подход от информационной системы. Что это значит? Вот у нас тут тот самый перегруженный интерфейс с некрасивыми кнопками, зато убийственно эффективный. Так вот, банально data-centric security подход, каждый чих там пользователя, когда перехватывается, он перехватывается с пачкой атрибутов, то есть контентная часть, что именно человек отправил по какому-то каналу и ворох атрибутов, кто был в копии, сколько вложений, что это за типы вложений, IP, MAC-адрес и так далее.
То есть нас интересует, по сути, чаще всего в расследовании учетка, из-под которой были совершены те или иные действия тем или иным пользователем. И это классно, это работает, это вроде бы очень удобно, и в разных ипостасях можно применять, в том числе, следуя правильным советам, иногда действительно лучше отрисовывать какой-то граф, потому что в таблице глаз замыливается. То есть некоторые связи, которые в таблице отображены, вообще глазу не очевидны, что оказывается это была какая-то веерная рассылка от одного внешнего контакта или еще что-то. Что вот эти 10 строк на самом деле это такой куст, от которого с одного узла расходится 10 писем.
Однако главная проблема при подходе от информационной системы – мы должны как-то быть интегрированы с этой информационной системой, чтобы максимально, в идеале на драйверном уровне из операционки, вытаскивать действия пользователя. Вот перед вами кусок уже не DLP, а DCAP-системы, Data-Centric Audit and Protection, где зафиксированы действия пользователя с тем или иным файлом, то есть на драйверном уровне. Почему это необходимо? Потому что не всегда, например, агент может все вам достать. То есть агент той или иной системы, агент, ну давайте в моих терминах, агент DLP-системы очень хорош в винде, практически так же хорош на разных никсах, не очень хорош пока что в macOS и практически бесполезен, если у нас есть облачная логика.
То есть если пользователь открыл помянутый уже Google Workspace, открыл документы в этом Google и начал писать там план по захвату и развалу компании полностью. Вот прям там в текстовом облачном редакторе. С точки зрения агента и действий, которые мы зафиксируем относительно пользователя, что мы увидим? Кейлогером, допустим, мы увидим, что он пишет в том или ином процессе или еще что-то, но кейлогер перехватывает потоково. Если пользователь дошел до пункта 10, потом поправил что-то в пункте номер 2, у нас все равно такая абракадабра получается, с одной стороны. С другой стороны, самый главный инструмент, если пользователь все это делал в браузере, вроде бы нам надо встроиться в HTTPS, в транспорт, все пакеты поперехватывать и увидеть, что пользователь писал вот такой плохой документ.
Но мы не можем этого сделать, в смысле собрать в кучу весь этот документ, потому что в той самой облачной логике за один раз в пакете передается только небольшое изменение состояния. То есть человек начинает писать там план по захвату компании. В первом пакете передается какая-нибудь техническая требуха, какой шрифт, какое что, а значимая часть там передается, ну, ПЛ, две буквы. В следующем пакете передается АН, еще одном, еще что-то. В итоге формально весь перехват у вас есть, а цельного документа для анализа нет. А он где есть? Он есть, если вы интегрированы по API с тем же самым Google Workspace, с ВК, с Яндекс 360, с M365 или Office 365 через Graph API и так далее. И очевидно, в данном случае проблема какая?
Собственно, проблема в том, что со всеми подряд не наинтегрируешься. Поэтому помимо подхода от информационной системы, я рассматриваю в качестве помощи в стеганографии еще два подхода. Подход обозвал его от пользовательской сессии, то есть неважно в каком приложении сидит пользователь, неважно как он это делает, через облако, просто через VDI и так далее. В данном случае что получается? Здесь контрастно не видно, но, например, на драйверном уровне выводятся те или иные водяные знаки, то есть на все мониторы и так далее. Откуда вообще такое решение взялось в мире? От проблемы фотографирования экрана на смартфон. То есть все, бесполезно вести какие-то логи. Пользователю доступен этот файл, эта информация. Он легитимно получил к ней доступ.
И при этом DLP-система тоже бессильна. То есть за доступ у нас отвечает всякое разное, в том числе и DCAP. DLP отвечает за контроль информации в движении, если пользователь решит пересылать эти файлы, но пользователь не пересылает, он открыл и сфоткал. Поэтому, исходя из этой проблемы, получили подход от пользовательской сессии. То есть как вариант, вывод водяных знаков, то есть та или иная информация техническая выводится и так далее. Для чего? Как раз таки, если мы будем двигаться по линии жизни инцидента, то есть когда утечка случается и всплыли какие-то скриншоты, те самые, снятые через принтскрин или снятые на смартфон снимки, то скриншот со скрытым водяным знаком ускорит отработку инцидента. Тот самый безопасник возьмет и увидит, проявит эти водяные знаки, то есть имя пользователя, имя машины, дата, время, текст или что мы решили отобразить в данном водяном знаке. То есть этот подход используется на российском рынке, в том числе.
Вот пример, так сказать, коллег по цеху. Это публичный какой-то скриншот, который вытащил я. Это компания EveryTag, которая по сути все то же самое. Вот они говорят, что мы там можем запихнуть кучу разных атрибутов через пустоту. То есть та самая стеганография, когда каждый документ уникален, когда его запрашивает пользователь за счет того, что есть какие-то сдвиги, либо межстрочного интервала, отступы от абзацев, лево-право-вверх-вниз отступы и так далее. И вот за счет этого, по сути, можно потом, если всплывет скрин или фотка такого документа, или распечатка соответствующая, можно достать хэш и увидеть, что это там Вася Пупкин слил. То есть нужно это в дополнение к подходу от информационной системы. Однако очевидная проблема здесь тоже есть. Хорошо, мы по сути одну задачу решили, а проблем-то больше.
Думая об этих проблемах, я выделил их четыре. То есть первая проблема – ограничения у нас есть технические по форматам. Не в каждый формат ты внедришься, не в каждый формат ты сможешь запихать стеганографию, по сути, применить стеганографию. Хотя, может быть, и можешь. Тем не менее, есть с этим проблема. А что делать, допустим, с аудиофайлами? То есть ладно, текст, вот подход с предыдущего слайда, текст понятно, а аудио, когда сливают, что там делать? Непонятно. По архитектуре таких решений тоже бывают проблемы. По архитектуре в том плане, что в идеале надо каждого пользователя всегда обеспечить уникальной копией, уникальной версией файла в любой момент времени, чтобы это все менялось. И вновь у нас накладывается техническое ограничение по формату, да еще и к тому, что это что-то клиент-серверное и прочее, непонятно.
Технические проблемы по обнаружению меток, ахиллесова пята. Например, наши водяные знаки, которые на драйверном уровне можно просто разложить по всем мониторам и так далее. Если их сделать достаточно непрозрачными, чтобы они, в принципе, для глаза пользователя были не видны, то они отлично проявляются, если сделан скриншот. Однако, если использовался смартфон в коллаборации с русским богатырем Пересветом, то есть если пересветить снимок, сделать его слишком ярким, то, естественно, эти знаки пропадают. Надо что-то более надежное придумывать. Поэтому бывают еще и технические затыки по обнаружению меток. Ну и бывают, как по мне, исключительные еще ситуации. Пример одной из них, когда у нас, допустим, внедрили метку, файл, как-то ее там прописали, а человек берет, открывает этот файл и просто создает рядом такой же. Банально, если берем текстовый документ, человек легитимно открыл документ, не снимает его на смартфон, не копирует оттуда и не вставляет информацию, а берет и просто создает новый, полностью уникальный документ, поразительно, добуквенно, с таким же содержимым.
Как быть? Никак. И получается так, что здесь стеганография тоже нам не помощник в плане того, как эта метка там окажется вдруг. Поэтому, в принципе, с учетом представленных ограничений получается такая идея. Это нерешенная проблема. То есть я не пришел вам продавать каких-то наших слонов на тему «вот смотрите, вы всю жизнь жили неправильно, а теперь заживем». Нет. Тем не менее, популярность подхода со стеганографией в последние два года выросла, запрос вырос, количество обращений у нас, у клиентов тоже выросло, что давайте тоже внедрять. Ну и попытки решить эту проблему приводят к следующим выводам, как по мне.
С одной стороны, вряд ли получится сделать что-то универсальное, которое будет применимо ко всем каналам передачи информации и ко всем форматам, в первую очередь, передачи информации. Ну и третья переменная к способу внедрения такой метки или чего бы то ни было. То есть, ну, как бы стеганография, что это у нас? Это у нас, когда мы в одной информации сокрыли другую информацию, скажем так, ну, очень упрощенно. В итоге получается для разных каналов, например, для принтера, все-таки удобнее использовать что-то свое. Для аудиофайлов или чертежей что-то свое лучше придумать. Для текстовой информации что-то третье будет хорошо работать. Это первый вывод. Второй вывод. Можно ли, в принципе, что-то универсальное все-таки попытаться сделать, чтобы охватывало, по крайней мере, большинство ситуаций?
На мой взгляд, да. С точки зрения, опять же, трактовки термина стеганография, я верю, что это могут быть метки. Но эти метки охватывают те случаи, когда у нас все-таки информация еще не утекла. Но, по крайней мере, мы не дадим информации вообще покинуть периметр защищаемый. Метки имеются в виду метки, которые можно проставлять на адрес файла в системе или же метки, которые непосредственно дописывать в метаданные файла. То есть опять же мы возвращаемся к тем же водяным знакам, которые, например, применяют производители софта для создания дипфейков тех или иных. То есть они заключили такое мировое соглашение и обязались ответственно разрабатывать свои инструменты. И вот если пользуется кто-либо их инструментом для создания аудиофайлов, там спектр или еще куда, в общем, внедряются свои водяные знаки.
Потом детекторы хорошо детектят. Вот, соответственно, с файлами тоже есть такой вариант: на основе тех или иных правил либо использовать автоматическую метку, либо в параллель использовать еще метку, вот эту, наши ручные метки, то есть метку, которая непосредственно дописывается куда-то файл. Естественно, скрыто, естественно, ее оттуда не выкорчевать, естественно, чтобы она наследовалась. И в этом ключе стеганография у нас не решит полностью проблему утечки, но она в связке с логикой RMS в принципе позволит тогда прийти к следующей ситуации. То есть, грубо говоря, чтобы файл при передаче за пределы защищенного периметра шел всегда в зашифрованном виде. И если он дошел не тому адресату, собственно, нельзя было этой информацией тогда воспользоваться.
А шифрование тогда будет идти на основе метки. То есть мы, по сути, берем известную модель атрибутивного доступа, attribute-based access control, и доворачиваем к ней шифрование, к этой логике, по сути, переизобретая вот этот Microsoft RMS, который когда-то был, и оказывается, сейчас на него снова есть спрос. То есть вот такие идеи, в сторону этих идей рынок российский, на мой взгляд, движется. Движемся здесь и мы с разной степенью успеха по разным каналам. Ну и хотелось бы как раз таки мнение или контраргументы присутствующих тоже по этому поводу услышать. То есть стеганография – это штука не такая уж и страшная, как по мне.
Определенную пользу она принесет, но не стоит думать, что это единственный инструмент, который решит все проблемы. Это просто дополнение. Лично мое мнение, что в принципе лучший инцидент – это тот, который не произошел. Поэтому не стоит его вообще доводить до реализации, а подбивать всех инсайдеров на взлете еще, когда они проходят стадию формирования намерений или стадию накопления информации. У меня все, спасибо.
— Алексей, большое спасибо. Так, переходим к вопросам.
— Здравствуйте, спасибо большое за доклад. Первое, это даже не вопрос, а такое небольшое дополнение по поводу аудио, потому что ватермарки для звука, они чуть ли не с 90-х годов существуют. А второй вопрос. Как вы относитесь к механизмам, которые используются в Canarytokens? Например, тот же самый нулевой пиксель, который встраивается в документ для того, чтобы потом отслеживать, был этот документ открыт или нет.
Нулевой пиксель в данном случае понимаю, но негативно отношусь по какой причине. По сути тогда мы порождаем необходимость активного действия, то есть риск демаскировки. Грубо говоря, у меня даже в лаборатории было такое упражнение, шпионский этот пиксель. Картинка из одного пикселя внедряется в документ, и если его слили и документ открыли, отстукивается в какой-нибудь сервис типа IP-логгера. Соответственно, в чем проблема? В том, что у нас, как только такой документ открывается, у нас начинает что-то там лететь, что-то куда-то стучится. А возможно, безопаснику не надо демаскировать себя. То есть штука полезная, штуку можно применять, нужно с умом, но такой функционал должен быть отключаемым, мне кажется.
— Спасибо большое.
— Так, коллеги, еще вопросы? Рук не вижу. Алексей, большое спасибо. Ой-ой-ой, опять колонка. Алексей, большое спасибо. Давайте проводим спикера аплодисментами еще раз. Это было круто.