Почему-то многие воспринимают описанный метод именно в контексте вывода информации из периметра удаленным пользователем, который сам находится вне периметра. И так понятно, что такой вывод информации - это достаточно простая задача, хотя и со своими нюансами. Но только этот сценарий в статье вообще не рассматривается. Вынужден цитировать свои же комментарии
в статье, рассматривается не тот сценарий, когда удаленный пользователь ставит себе задачу вывести файл из периметра, находясь за ним. Рассматриваются сценарии, когда описанным методом удаленный пользователь может затащить сторонний файл внутрь периметра, а также скрытно и автоматизировано вывести конфиденциальный файл наружу, находясь внутри периметра, и не попавшись при этом в DLP.
Вы абсолютно правы, в Linux это делается ещё проще, например вот так: echo -n -e '\x66\x6f\x6f' > test.txt Но суть статьи не в том, каким именно способом удаленный злоумышленник запишет hex-символы в полубайты на целевом корпоративном ресурсе, а в том, что: а) это принципиально возможно, если на целевом ресурсе должным образом не выполняются меры по ОПС (ограничение программной среды, выше просили расшифровать этот ИБшный термин); б) для этого нарушителю понадобится программная (или программно-аппаратная, если он имеет дело с LiveUSB-токенами) автоматизация, которая сейчас очень даже доступна (нейронки, BadUSB-устройства), и безопасники должны это учитывать при моделировании угроз; в) сетевые СрЗИ не отловят файл на анализ, т.к. он передается не стандартным способом, а набором текста в рамках терминальной сессии. Вероятно, даже всплеска сетевого трафика не будет, а значит не будет интерпретировано сетевыми СрЗИ, как сетевая аномалия.
Если человек уже внутри системы, зашел со своим логином/паролем, то организация, как минимум, ему доверяет до того уровня, насколько у его логина хватает прав.
К сожалению, так бывает только в идеальном мире. На практике же, даже неочевидная и небольшая избыточность в правах, как мы видим, может создать канал для неконтролируемой передачи данных из/наружу.
Если требуемой для вывода информации в единицу времени генерируется больше, чем пропускная способность канала - то, это достаточно очевидно. Но задача не в том, чтобы собрать постоянно генерируемый объём данных из удаленной системы, метод этого и не преследует, что описано в выводах.
вы человеку на дислплей вывели экран защищенной системы. То есть перевели ее в электромагнитные волны видимого диапазона. Снять эту информацию и записать в файл за пределами защищенного контура - это вопрос желания, а не возможностей!
Это только в том случае, если выводимая на экран информация - человекочитаема. Если же эта информация представляет ценность только в виде файла, но не является человекочитаемой, то так просто "в лоб" решить не получится. Как минимум, потребуется отобразить файл в "сыром" или хотя бы в символьном, но однозначно интерпретируемом для последующей обработки виде. Но, вообще говоря, в статье, рассматривается не тот сценарий, когда удаленный пользователь ставит себе задачу вывести файл из периметра, находясь за ним. Рассматриваются сценарии, когда описанным методом удаленный пользователь может затащить сторонний файл внутрь периметра, а также скрытно и автоматизировано вывести конфиденциальный файл наружу, находясь внутри периметра, и не попавшись при этом в DLP.
Не совсем понимаю, как вы предлагаете решать задачу копирования файла на удаленный ресурс через QR-коды. Предлагаете на целевом ресурсе установить сканер QR-кодов, что как бы технически сложнее для нарушителя? А как камеру оттуда навести на штрихкод? С динамиками тоже все понятно, способов передать информацию бывает много. Вопрос в том, какие из них нарушитель может наиболее просто и скрытно применить в наиболее типовых условиях и инфраструктурах. А последнее предложение прям улыбнуло, спасибо)
Под обратной задачей тут понимается скрытый вывод данных наружу пользователем, который находится внутри периметра с использованием программной эмуляции клавиатуры. Подробней этот кейс раскрыт в разделе о DLP и о принципах защиты.
Складывается ощущение, что гораздо эффективнее будет решить задачу через запрет на запуск на АРМ пользователя любого стороннего ПО, не входящего в заранее сформированный белый список, чем писать правила детектирования под каждый возможный файл, который потенциально может создать канал утечки. Если пользователь в принципе может запустить произвольный исполняемый файл в своей рабочей среде, то что ему мешает запустить не мессенджер, а ПО для стеганографии?
Суть тут в том, что подобные решения с доверенными оболочками как раз и помогают отсечь подобную угрозу, даже в том случае если домашняя операционная система пользователя уже скомпрометирована. Т.к. в процессе работы из такой оболочки, какой-либо информационный обмен с домашней ОС пользователя отсутствует.
Если кроме защиты канала связи никакие другие меры защиты не применяются, то основной риск тут в том, что среды удаленных пользователей могут быть скомпрометированы. А это, в свою очередь, может вести уже к самым разным вариантам развития событий, в т.ч. к попаданию и распространению ВПО внутри сети предприятия, сливу конфиденциальных данных, доступу внутрь неустановленных лиц с дальнейшим закреплением присутствия и т.д., что может привести к недопустимым событиям для бизнеса вашей компании.
Почему-то многие воспринимают описанный метод именно в контексте вывода информации из периметра удаленным пользователем, который сам находится вне периметра. И так понятно, что такой вывод информации - это достаточно простая задача, хотя и со своими нюансами. Но только этот сценарий в статье вообще не рассматривается.
Вынужден цитировать свои же комментарии
Вы абсолютно правы, в Linux это делается ещё проще, например вот так:
echo -n -e '\x66\x6f\x6f' > test.txtНо суть статьи не в том, каким именно способом удаленный злоумышленник запишет hex-символы в полубайты на целевом корпоративном ресурсе, а в том, что:
а) это принципиально возможно, если на целевом ресурсе должным образом не выполняются меры по ОПС (ограничение программной среды, выше просили расшифровать этот ИБшный термин);
б) для этого нарушителю понадобится программная (или программно-аппаратная, если он имеет дело с LiveUSB-токенами) автоматизация, которая сейчас очень даже доступна (нейронки, BadUSB-устройства), и безопасники должны это учитывать при моделировании угроз;
в) сетевые СрЗИ не отловят файл на анализ, т.к. он передается не стандартным способом, а набором текста в рамках терминальной сессии. Вероятно, даже всплеска сетевого трафика не будет, а значит не будет интерпретировано сетевыми СрЗИ, как сетевая аномалия.
Это один из возможных описанных сценариев, который, при отсутствии должного ОПС на целевом ресурсе, можно реализовать с помощью описанной методики.
К сожалению, так бывает только в идеальном мире. На практике же, даже неочевидная и небольшая избыточность в правах, как мы видим, может создать канал для неконтролируемой передачи данных из/наружу.
Если требуемой для вывода информации в единицу времени генерируется больше, чем пропускная способность канала - то, это достаточно очевидно. Но задача не в том, чтобы собрать постоянно генерируемый объём данных из удаленной системы, метод этого и не преследует, что описано в выводах.
Это только в том случае, если выводимая на экран информация - человекочитаема. Если же эта информация представляет ценность только в виде файла, но не является человекочитаемой, то так просто "в лоб" решить не получится. Как минимум, потребуется отобразить файл в "сыром" или хотя бы в символьном, но однозначно интерпретируемом для последующей обработки виде. Но, вообще говоря, в статье, рассматривается не тот сценарий, когда удаленный пользователь ставит себе задачу вывести файл из периметра, находясь за ним. Рассматриваются сценарии, когда описанным методом удаленный пользователь может затащить сторонний файл внутрь периметра, а также скрытно и автоматизировано вывести конфиденциальный файл наружу, находясь внутри периметра, и не попавшись при этом в DLP.
Эх, долго придется ждать, пока я найду время на 700+ страничную фантастику. Но, спасибо за рекомендацию, обязательно поставлю в очередь на чтение👍
Не совсем понимаю, как вы предлагаете решать задачу копирования файла на удаленный ресурс через QR-коды. Предлагаете на целевом ресурсе установить сканер QR-кодов, что как бы технически сложнее для нарушителя? А как камеру оттуда навести на штрихкод? С динамиками тоже все понятно, способов передать информацию бывает много. Вопрос в том, какие из них нарушитель может наиболее просто и скрытно применить в наиболее типовых условиях и инфраструктурах. А последнее предложение прям улыбнуло, спасибо)
Очень хорошо, что мы с вами понимаем очевидность этого на бытовом уровне. Но очень жаль, что остальная часть статьи для вас осталась не актуальной.
Под обратной задачей тут понимается скрытый вывод данных наружу пользователем, который находится внутри периметра с использованием программной эмуляции клавиатуры. Подробней этот кейс раскрыт в разделе о DLP и о принципах защиты.
Складывается ощущение, что гораздо эффективнее будет решить задачу через запрет на запуск на АРМ пользователя любого стороннего ПО, не входящего в заранее сформированный белый список, чем писать правила детектирования под каждый возможный файл, который потенциально может создать канал утечки. Если пользователь в принципе может запустить произвольный исполняемый файл в своей рабочей среде, то что ему мешает запустить не мессенджер, а ПО для стеганографии?
Суть тут в том, что подобные решения с доверенными оболочками как раз и помогают отсечь подобную угрозу, даже в том случае если домашняя операционная система пользователя уже скомпрометирована. Т.к. в процессе работы из такой оболочки, какой-либо информационный обмен с домашней ОС пользователя отсутствует.
Если кроме защиты канала связи никакие другие меры защиты не применяются, то основной риск тут в том, что среды удаленных пользователей могут быть скомпрометированы. А это, в свою очередь, может вести уже к самым разным вариантам развития событий, в т.ч. к попаданию и распространению ВПО внутри сети предприятия, сливу конфиденциальных данных, доступу внутрь неустановленных лиц с дальнейшим закреплением присутствия и т.д., что может привести к недопустимым событиям для бизнеса вашей компании.
Уточните пожалуйста, какой конкретно продукт имеете в виду, и в чем именно вопрос?