— последующие меры чего? Когда подмена и какого протокола (или эмуляция) может потребоваться? Почему нельзя подменить протокол или эмулировать что-то в последствии?
Тут мы имели в виду, что можно осуществлять проактивную реакцию. Например, убирать SSL, заворачивать трафик на определённый прокси, закидывать хост, с которого идёт подозрительная активность, в VLAN, эмулирующий корпоративную сеть, и делать прочие забавные штуки, чтобы потом разобраться, что это была за активность.
В последствии всё можно сделать, но не до конца эффективно. Мы встречали малварь, которая запоминала SSL-сертификат сервера, и если был другой, то самоудалялась. С эмуляцией могут быть такие же вещи (на практике не видели, но всё может быть).
Что за «точность» подразумевается в захвате трафика? Разве можно его захватывать «не точно»?
Тут мы имели в виду, что нам всё равно, на каком порту поднято TLS-соединение. TLS-рукопожатие легко детектится на любом порту.
Т.е. захватывается односторонний трафик «только от клиента к серверу» (под описание трафик «от сервера к клиенту» тоже подходит)? Почему так? Это не совсем «нулевое требование», нужно явным образом запретить принимать одно из направлений, потому что по умолчанию дампятся оба направления.
Тут не совсем понятно. Задачи при базовом фингерпринтинге — захватить начало TLS-рукопожатия. Нам не нужно производить глубокий анализ следующих пакетов (как это делают DPI-системы). Про нулевые требования, это мы лихо сказали конечно.
Почему в среде с ассиметричной маршрутизацией будет отбрасывание пакетов? Какое дело датчикам до симметрии, это же датчики в работающей среде, а не «только что установленный FW, который не может поддержать statefull-сессию из-за того, что часть трафика мимо него прошла».
Фраза про отброс пакетов относится к “с ограничениями ресурсов”, и опять повторю, что наша цель — захватить начало TLS-соединения, а дальше при фингерпринтинге нам всё равно, что происходит в сети — идут ли отбросы пакетов, перестроение маршрутов и т.д. Мы свои данные получили (опять сошлюсь на DPI-системы, которые в таких условиях и с частичной информацией работать не будут).
А как приветствие клиента можно спрятать на нестандартном порту? Можно чуть подробнее, пожалуйста?
Именно, что никак!
Датчики с небольшими ресурсами могут собирать пакеты, которые им шлёт клиент, в среде с ассиметричной маршрутизацией, независимо от порта с которого клиент прислал пакет. Так, правильно? У вас именно так написано. Значит ли, что в среде с симметричной маршрутизацией сбор пакетов уже будет зависеть от порта с которого они пришли? Я честно не понимаю что вы имели в виду и как это у вас работает в теории хотя бы.
Клиент — это роутер, датчик — это приёмник трафика по span-порту или аналогу.
Суть — TLS handshake легко получать из зеркалируемого трафика, и его анализ не ресурсозатратен.
Про пример — вы правы. Картинка не имеет никакого отношения к дальнейшим шагам (тут наш косяк, категорически не правы, не вычитали). Для глубокого понимания рекомендую читать оригинальную статью авторов JA3.
В реальной работе мы считаем хэши JA3/JA3S, используя Zeek. Всё теоретическое описание в статье дано для общего понимания. Извиняемся, что ввели в заблуждение.
AirWatch больше не существует, теперь это Workspace One :)
Оба решения применяются для защиты мобильных устройств и обладают, в целом, схожим функционалом. Отличие — в нюансах управления, поддерживаемых платформах и, разумеется, ценовой политике.
Здравствуйте!
Приложение Proget MDM ставится на личное устройство, как правило, в базовом виде интеграции, например, Android MDM. Поскольку агент ставится в виде обычного приложения, он имеет такие же разрешения или ограничения в системе, как и любые другие приложения на устройстве. Настройки безопасности самой мобильной ОС не позволяют считывать приложениям любую информацию с устройства или с других приложений, тем более платёжных систем, пока пользователь сам не предоставит такие разрешения.
• что насчет применимости УК РФ по ЗИ субьекта, обьекта КИИ РФ на базе вашего примера, в плане ответственности в случае возникновения инцидента — если рекомендательные документы, без обязующих к выполнению НПА, были не рассмотрены организацией или были приняты на «свое усмотрение» ответственным лицом? Вопрос составлен при условии того, что «новизна» и «изменчивость» КИИ идут от 2018 года, где хотелось бы понимать практическую значимость, которую вы видите, а желательно прочитать ваши мысли в формате: как обезопасить ответственной лицо, даже в ситуации «общего» характера — при условии вашего опыта ;)
На текущий момент в УК РФ отсутствует ответственность за невыполнение требований каких-либо НПА в области защиты КИИ. Санкции могут быть применены, например, в случае нарушения правил эксплуатации объекта КИИ или системы защиты объекта КИИ (ч. 3 ст. 274.1 УК РФ).
Что касается «обезопасить ответственное лицо», то сложно сказать что-то более конкретное, чем «обеспечивайте защиту инфраструктуры, даже если объектам КИИ не присвоена категория значимости», все-таки подход к обеспечению защиты информации, выполнению требований НПА довольно сильно зависит от особенностей объекта защиты и его владельца.
• как можно минимизировать риски по БП для отдела ИБ не «ставя палки в колеса» бизнесу, в данном примере, если есть обязательные СЗИ и есть рекомендуемые в плане применимости на базе ДОУ (включаемые с категорированием информации по видам тайн, не рассматривая ГТ — как вы и указывали), включая уже упомянутую вами ИСПДн? Я понимаю, что все зависит от уровня ущерба по оценке возникновения риска — которые рассматриваются в отдельных ИС, включаемых в циклы процессной деятельности организации, но вопрос стоит вокруг изменений и нормативной базы в плане СЗИ в нынешних условиях применимости НКЦКИ ГосСОПКА, включая формат типизации на базе ПИБО, которая строится от модели нарушителя, атак и угроз.
«Палки в колеса» от сертифицированных СЗИ ненамного больше, чем от любых других. Так что вопрос скорее должен относиться к системе защиты как таковой. И решается он, как Вы правильно указали, с учетом оценки возможного ущерба.
• что стоит делать, если СПО СЗИ/КСЗИ, которое было выбрано при перекрытии угроз на базе моделей и делегирования доступов нарушителей — дублирует действующий функционал друг друга с перекрытием и усложнением БП?
Как вы могли понять из нашего материала, случаев, когда необходимо использовать именно сертифицированные СЗИ/СКЗИ не так и много, особенно если речь идет о коммерческих организациях. Поэтому вопрос дублирования функционала возникает скорее в качестве исключения, чем практики. В подобных случаях считаем необходимым отталкиваться от рисков, которые ставит перед собой организация.
• можно ли упростить всю «процессию» при условии применения самостоятельного решения в плане автоматизации БП организации и свести все к моделям распределения уровней значимости системы, такого типа как MLS? В вашем примере приведены данные в формате
Что касается использования СКЗИ, для организаций реализующих 1-ый уровень защиты, необходимо использовать сертифицированные ФСБ России СКЗИ. Для остальных организаций действует правило, согласно которому все используемые СКЗИ российского производства также должны быть сертифицированными.
— если вы рассматриваете данный пример, тогда каким образом строится формат применимости СПО, относительно БДУ ФСТЭК России, включая покрытие на базе моделей нарушителя, атак и угроз? Речь скорее не про построение моделей, а в плане применимости СЗИ и ее «обязательности».
БДУ в данном случае может использоваться исключительно в качестве базы знаний об угрозах и уязвимостях. Решение же об использовании тех или иных СЗИ принимается на основе факторов, к которым в том числе относятся: а) актуальные угрозы безопасности и их источники; б) требования по обеспечению ЗИ, устанавливаемые применимыми НПА.
• как долго данный формат сертификации/аттестации может проходить на практике?
О каком именно формате идет речь? Процессы сертификации и аттестации не являются взаимозаменяемыми, хотя бы с точки зрения объектов, в отношении которых они проводятся. Если имеется в виду процесс сертификации средства защиты информации, то его длительность зависит как минимум от требований, соответствие которым предполагается оценить – может составлять как несколько месяцев, так и год.
• есть ли у вас какая-то методология по введению в промышленную эксплуатацию?
Опять же не совсем понятно о вводе чего в эксплуатацию идет речь. Если речь про системы защиты, построенные с учетом требований НПА, то весь процесс описан в этих самых НПА, как и любой другой этап жизненного цикла таких систем. Если же имеются в виду средства защиты, то тут нужно отталкиваться прежде всего от реализуемого ими функционала: где-то достаточно установить ряд основных параметров и отключить учетные записи по умолчанию, где-то этот процесс сложнее. В любом случае, порядок ввода в эксплуатацию прописывается в эксплуатационной документации на само средство защиты.
• если финансовая организация использует СКЗИ российского производителя, то оно должно иметь сертификат ФСБ России.
— что насчет обязательного импортозамещения продуктов на рынке ИБ, включая рассматривание модели нарушителя, в которой иностранный софт, а также лица — являются «угрозой»?
Модель угроз разрабатывается владельцем объекта защиты с учетом особенностей этого самого объекта. И если в результате моделирования угроз будет определено, что угрозы с наличием НДВ в «преимущественно иностранных СЗИ» актуальны, то защищаться от них каким-либо образом придется. С другой стороны, если подобные угрозы не признаны актуальными по объективным причинам, то и строить систему защиты от них не имеет смысла. При этом стоит помнить, что особняком стоит вопрос об импортозамещении ПО, устанавливаемый отдельными НПА, например, для КИИ.
Отсутствие необходимости использования сертифицированного ФСБ МЭ, на самом деле, достаточно часто встречается в практике. Например, в случае когда СКАД Сигнатура функционирует на отдельном рабочем месте, не подключенном к сетям связи общего пользования, и каналы передачи информации от/на криптосредство не выходят за пределы контролируемой зоны.
Однако даже этот момент можно назвать весьма "тонким" с учетом присутствующей неоднозначности трактовок, приведенных в эксплуатационной документации, а также периодически меняющегося мнения регуляторов на этот счёт
Цель статьи — понять, какие действующие документы (из довольно внушительного списка НПА) требуют использования сертифицированных решений, а какие нет. Тем самым немного упростив задачу организациям, освободив их от необходимости самостоятельно изучать многостраничные тексты. Оценивать эффективность сертифицированных СЗИ не предполагалось, поэтому в статье и отсутствуют оценочные суждения.
Тем не менее, сам вопрос выбора действительно работающих и эффективных СЗИ важен и должен быть рассмотрен при реализации системы защиты в любой компании.
Замечание по делу, но пока что нашей целевой (и даже случайной) аудиторией не являются субъекты из ЕС, поэтому для себя мы этот риск оценили и приняли. Сайт не был представлен в статье как эталонный образец выполнения требований по GDPR, но мы над этим работаем :)
Я правильно понимаю, что SSLsplit для клиента превратила https в http-соединение?
Да, именно так. Сам SSLsplit строит https-сессию до сайта, клиенту возвращается http-соединение.
А браузер клиента не выдал никаких ошибок, когда изначально пытался открыть https-сайт, а вместо этого получил http?
Да, ошибки появиться могут, но в основном из-за того, что в истории сохранились https-соединения. Ну или если это сайт из списка «захордкоженных HSTS». В первом случае я вижу выход в совмещении атаки с соц.инженерией, например, во втором случае все «грустно».
В теории это возможно, однако, необходимо будет решить ряд задач:
1. Мы запускаем сканеры по определенному расписанию, ориентируясь на результаты инвентаризации. Для этого написаны определенные скрипты, составлены профили сканирования. Кому-то необходимо будет проделать эту работу на внешнем сканере (либо предоставить доступ нашим инженерам).
2. Описанную выше работу нужно будет поставить как процесс, поскольку все меняется и профили сканирования приходится часто редактировать.
3. Нужно будет настроить автоматическую выгрузку результатов в нашу SIEM-систему, попутно обезопасив этот процесс, поскольку данные достаточно чувствительные.
Важно понимать, что ключевой частью услуги по ресурсоемкости является именно оценка результатов, разработка рекомендаций и консультирование представителей клиентов, а используемые сканеры являются, скорее, окружением для неё.
Ответ на вопрос про сбор данных об активах:
Услуга строится на инвентаризации и, как следствие, сканировании, поэтому в таком случае данные сегменты приходится исключать из проекта. В целом, тут стоит вопрос о доверии или желании заказчика.
Ответ на вопрос про закрытие уязвимостей:
Да, бывают, в основном в больших компаниях, где с оборудованием работают люди невовлечённые в сам процесс. Во избежания нарушений процессов контроля устранения уязвимостей выставляются предварительно согласованные сроки закрытия. Если баги не закрыты в срок, то выясняется причина. Таким образом, мы понимаем, что либо заявка действительно не закрыта по каким-то причинам, либо о её закрытии забыли сообщить.
Спасибо, немного изменили текст, чтобы не быть столь категоричными. Однако количество случаев, когда это действительно нужно значительно ниже, количество случаев, когда без этой настройки можно было бы и обойтись. На наш взгляд, гораздо лучше говорить людям, что так делать не стоит. Те, кто действительно понимают, что делают, проигнорируют такие советы, а те, кто не понимают, не наступят на грабли лишний раз.
Спасибо, что обратили внимание на скриншоты. Теперь они кликабельны, и вы можете получить полную информацию.
На практике атаки MITM на физическом уровне на пользователей довольно редки, в рамках своих аудитов мы говорим:«смотрите, так можно сделать, у вас нет защиты от этого», но MITM конкретного пользователя мы не производим. На канальном уровне (ARP-спуфинг) рассказы о конкретных примерах буду иметь следующий вид: «мы запустили ARP-спуфинг, его не обнаружили средства защиты, мы подождали и получили креды от сайта». Или же: «мы долго ждали и получили креды от telnet или ftp (может ими пользуется кто-то ещё)». Нам кажется такой рассказ неинтересным.
Если говорить о mitmproxy и прочих подобных инструментов, они работают не на физическом и канальном уровнях. Мы обратимся к этим инструментам в следующих статьях.
Речь идет не про устройства, а про спецификации, которые после определённого количества времени Bluetooth SIG считает устаревшими. Подробнее ссылки даны тут: www.bluetooth.com/specifications/bluetooth-core-specification/archived-specifications.
И по идее, все версии Bluetooth обратно совместимые. Однако, не стоит забывать о проблемах, которые были, например, в версии 1.0 — устройства разных вендоров могли и не быть совместимыми.
Многократное хэширование увеличивает вероятность коллизий, но это не критично и многие его используют.
Об этом можно прочитать здесь: habr.com/post/100301
Тут мы имели в виду, что можно осуществлять проактивную реакцию. Например, убирать SSL, заворачивать трафик на определённый прокси, закидывать хост, с которого идёт подозрительная активность, в VLAN, эмулирующий корпоративную сеть, и делать прочие забавные штуки, чтобы потом разобраться, что это была за активность.
Подмена протокола – убрать TLS (да, написали криво).
В последствии всё можно сделать, но не до конца эффективно. Мы встречали малварь, которая запоминала SSL-сертификат сервера, и если был другой, то самоудалялась. С эмуляцией могут быть такие же вещи (на практике не видели, но всё может быть).
Тут мы имели в виду, что нам всё равно, на каком порту поднято TLS-соединение. TLS-рукопожатие легко детектится на любом порту.
Тут не совсем понятно. Задачи при базовом фингерпринтинге — захватить начало TLS-рукопожатия. Нам не нужно производить глубокий анализ следующих пакетов (как это делают DPI-системы). Про нулевые требования, это мы лихо сказали конечно.
Фраза про отброс пакетов относится к “с ограничениями ресурсов”, и опять повторю, что наша цель — захватить начало TLS-соединения, а дальше при фингерпринтинге нам всё равно, что происходит в сети — идут ли отбросы пакетов, перестроение маршрутов и т.д. Мы свои данные получили (опять сошлюсь на DPI-системы, которые в таких условиях и с частичной информацией работать не будут).
Именно, что никак!
Клиент — это роутер, датчик — это приёмник трафика по span-порту или аналогу.
Суть — TLS handshake легко получать из зеркалируемого трафика, и его анализ не ресурсозатратен.
Про пример — вы правы. Картинка не имеет никакого отношения к дальнейшим шагам (тут наш косяк, категорически не правы, не вычитали). Для глубокого понимания рекомендую читать оригинальную статью авторов JA3.
В реальной работе мы считаем хэши JA3/JA3S, используя Zeek. Всё теоретическое описание в статье дано для общего понимания. Извиняемся, что ввели в заблуждение.
Оба решения применяются для защиты мобильных устройств и обладают, в целом, схожим функционалом. Отличие — в нюансах управления, поддерживаемых платформах и, разумеется, ценовой политике.
Приложение Proget MDM ставится на личное устройство, как правило, в базовом виде интеграции, например, Android MDM. Поскольку агент ставится в виде обычного приложения, он имеет такие же разрешения или ограничения в системе, как и любые другие приложения на устройстве. Настройки безопасности самой мобильной ОС не позволяют считывать приложениям любую информацию с устройства или с других приложений, тем более платёжных систем, пока пользователь сам не предоставит такие разрешения.
• что насчет применимости УК РФ по ЗИ субьекта, обьекта КИИ РФ на базе вашего примера, в плане ответственности в случае возникновения инцидента — если рекомендательные документы, без обязующих к выполнению НПА, были не рассмотрены организацией или были приняты на «свое усмотрение» ответственным лицом? Вопрос составлен при условии того, что «новизна» и «изменчивость» КИИ идут от 2018 года, где хотелось бы понимать практическую значимость, которую вы видите, а желательно прочитать ваши мысли в формате: как обезопасить ответственной лицо, даже в ситуации «общего» характера — при условии вашего опыта ;)
На текущий момент в УК РФ отсутствует ответственность за невыполнение требований каких-либо НПА в области защиты КИИ. Санкции могут быть применены, например, в случае нарушения правил эксплуатации объекта КИИ или системы защиты объекта КИИ (ч. 3 ст. 274.1 УК РФ).
Что касается «обезопасить ответственное лицо», то сложно сказать что-то более конкретное, чем «обеспечивайте защиту инфраструктуры, даже если объектам КИИ не присвоена категория значимости», все-таки подход к обеспечению защиты информации, выполнению требований НПА довольно сильно зависит от особенностей объекта защиты и его владельца.
• как можно минимизировать риски по БП для отдела ИБ не «ставя палки в колеса» бизнесу, в данном примере, если есть обязательные СЗИ и есть рекомендуемые в плане применимости на базе ДОУ (включаемые с категорированием информации по видам тайн, не рассматривая ГТ — как вы и указывали), включая уже упомянутую вами ИСПДн? Я понимаю, что все зависит от уровня ущерба по оценке возникновения риска — которые рассматриваются в отдельных ИС, включаемых в циклы процессной деятельности организации, но вопрос стоит вокруг изменений и нормативной базы в плане СЗИ в нынешних условиях применимости НКЦКИ ГосСОПКА, включая формат типизации на базе ПИБО, которая строится от модели нарушителя, атак и угроз.
«Палки в колеса» от сертифицированных СЗИ ненамного больше, чем от любых других. Так что вопрос скорее должен относиться к системе защиты как таковой. И решается он, как Вы правильно указали, с учетом оценки возможного ущерба.
• что стоит делать, если СПО СЗИ/КСЗИ, которое было выбрано при перекрытии угроз на базе моделей и делегирования доступов нарушителей — дублирует действующий функционал друг друга с перекрытием и усложнением БП?
Как вы могли понять из нашего материала, случаев, когда необходимо использовать именно сертифицированные СЗИ/СКЗИ не так и много, особенно если речь идет о коммерческих организациях. Поэтому вопрос дублирования функционала возникает скорее в качестве исключения, чем практики. В подобных случаях считаем необходимым отталкиваться от рисков, которые ставит перед собой организация.
• можно ли упростить всю «процессию» при условии применения самостоятельного решения в плане автоматизации БП организации и свести все к моделям распределения уровней значимости системы, такого типа как MLS? В вашем примере приведены данные в формате
Что касается использования СКЗИ, для организаций реализующих 1-ый уровень защиты, необходимо использовать сертифицированные ФСБ России СКЗИ. Для остальных организаций действует правило, согласно которому все используемые СКЗИ российского производства также должны быть сертифицированными.
— если вы рассматриваете данный пример, тогда каким образом строится формат применимости СПО, относительно БДУ ФСТЭК России, включая покрытие на базе моделей нарушителя, атак и угроз? Речь скорее не про построение моделей, а в плане применимости СЗИ и ее «обязательности».
БДУ в данном случае может использоваться исключительно в качестве базы знаний об угрозах и уязвимостях. Решение же об использовании тех или иных СЗИ принимается на основе факторов, к которым в том числе относятся: а) актуальные угрозы безопасности и их источники; б) требования по обеспечению ЗИ, устанавливаемые применимыми НПА.
• как долго данный формат сертификации/аттестации может проходить на практике?
О каком именно формате идет речь? Процессы сертификации и аттестации не являются взаимозаменяемыми, хотя бы с точки зрения объектов, в отношении которых они проводятся. Если имеется в виду процесс сертификации средства защиты информации, то его длительность зависит как минимум от требований, соответствие которым предполагается оценить – может составлять как несколько месяцев, так и год.
• есть ли у вас какая-то методология по введению в промышленную эксплуатацию?
Опять же не совсем понятно о вводе чего в эксплуатацию идет речь. Если речь про системы защиты, построенные с учетом требований НПА, то весь процесс описан в этих самых НПА, как и любой другой этап жизненного цикла таких систем. Если же имеются в виду средства защиты, то тут нужно отталкиваться прежде всего от реализуемого ими функционала: где-то достаточно установить ряд основных параметров и отключить учетные записи по умолчанию, где-то этот процесс сложнее. В любом случае, порядок ввода в эксплуатацию прописывается в эксплуатационной документации на само средство защиты.
• если финансовая организация использует СКЗИ российского производителя, то оно должно иметь сертификат ФСБ России.
— что насчет обязательного импортозамещения продуктов на рынке ИБ, включая рассматривание модели нарушителя, в которой иностранный софт, а также лица — являются «угрозой»?
Модель угроз разрабатывается владельцем объекта защиты с учетом особенностей этого самого объекта. И если в результате моделирования угроз будет определено, что угрозы с наличием НДВ в «преимущественно иностранных СЗИ» актуальны, то защищаться от них каким-либо образом придется. С другой стороны, если подобные угрозы не признаны актуальными по объективным причинам, то и строить систему защиты от них не имеет смысла. При этом стоит помнить, что особняком стоит вопрос об импортозамещении ПО, устанавливаемый отдельными НПА, например, для КИИ.
Отсутствие необходимости использования сертифицированного ФСБ МЭ, на самом деле, достаточно часто встречается в практике. Например, в случае когда СКАД Сигнатура функционирует на отдельном рабочем месте, не подключенном к сетям связи общего пользования, и каналы передачи информации от/на криптосредство не выходят за пределы контролируемой зоны.
Однако даже этот момент можно назвать весьма "тонким" с учетом присутствующей неоднозначности трактовок, приведенных в эксплуатационной документации, а также периодически меняющегося мнения регуляторов на этот счёт
Тем не менее, сам вопрос выбора действительно работающих и эффективных СЗИ важен и должен быть рассмотрен при реализации системы защиты в любой компании.
Что вы имеете ввиду под тестовым набором?
Да, именно так. Сам SSLsplit строит https-сессию до сайта, клиенту возвращается http-соединение.
Да, ошибки появиться могут, но в основном из-за того, что в истории сохранились https-соединения. Ну или если это сайт из списка «захордкоженных HSTS». В первом случае я вижу выход в совмещении атаки с соц.инженерией, например, во втором случае все «грустно».
Для обхода HSTS, это выполняет SSLsplit.
1. Мы запускаем сканеры по определенному расписанию, ориентируясь на результаты инвентаризации. Для этого написаны определенные скрипты, составлены профили сканирования. Кому-то необходимо будет проделать эту работу на внешнем сканере (либо предоставить доступ нашим инженерам).
2. Описанную выше работу нужно будет поставить как процесс, поскольку все меняется и профили сканирования приходится часто редактировать.
3. Нужно будет настроить автоматическую выгрузку результатов в нашу SIEM-систему, попутно обезопасив этот процесс, поскольку данные достаточно чувствительные.
Важно понимать, что ключевой частью услуги по ресурсоемкости является именно оценка результатов, разработка рекомендаций и консультирование представителей клиентов, а используемые сканеры являются, скорее, окружением для неё.
Услуга строится на инвентаризации и, как следствие, сканировании, поэтому в таком случае данные сегменты приходится исключать из проекта. В целом, тут стоит вопрос о доверии или желании заказчика.
Ответ на вопрос про закрытие уязвимостей:
Да, бывают, в основном в больших компаниях, где с оборудованием работают люди невовлечённые в сам процесс. Во избежания нарушений процессов контроля устранения уязвимостей выставляются предварительно согласованные сроки закрытия. Если баги не закрыты в срок, то выясняется причина. Таким образом, мы понимаем, что либо заявка действительно не закрыта по каким-то причинам, либо о её закрытии забыли сообщить.
На практике атаки MITM на физическом уровне на пользователей довольно редки, в рамках своих аудитов мы говорим:«смотрите, так можно сделать, у вас нет защиты от этого», но MITM конкретного пользователя мы не производим. На канальном уровне (ARP-спуфинг) рассказы о конкретных примерах буду иметь следующий вид: «мы запустили ARP-спуфинг, его не обнаружили средства защиты, мы подождали и получили креды от сайта». Или же: «мы долго ждали и получили креды от telnet или ftp (может ими пользуется кто-то ещё)». Нам кажется такой рассказ неинтересным.
Если говорить о mitmproxy и прочих подобных инструментов, они работают не на физическом и канальном уровнях. Мы обратимся к этим инструментам в следующих статьях.
И по идее, все версии Bluetooth обратно совместимые. Однако, не стоит забывать о проблемах, которые были, например, в версии 1.0 — устройства разных вендоров могли и не быть совместимыми.
Об этом можно прочитать здесь: habr.com/post/100301