Новое руководство ОЭСР по трансфертному ценообразованию для финансовых операций
Юридическая компания «Пепеляев Групп» информирует о публикации Руководства ОЭСР по трансфертному ценообразованию для финансовых операций[1].
Одна из проблем определения налоговых последствий внутригрупповых финансовых операций (займов, поручительств и т.п.) состоит в крайне скудном нормативном регулировании вопросов ТЦО в отношении таких операций.
Так, российские правила ТЦО (раздел V.I НК РФ) содержат минимум положений, учитывающих специфику финансовых операций. При публикации нового Руководства на сайте ОЭСР также было обращено внимание на то, что аспекты ТЦО применительно к финансовым операциям рассматриваются в нем впервые.
Новое Руководство было разработано в рамках проекта BEPS, в котором участвует и Российская Федерация. Поэтому следует ожидать, что подходы, предложенные в Руководстве, будут использованы и в российской правоприменительной практике[2].
Основные вопросы, затрагиваемые Руководством
Существенное внимание уделено операциям внутригруппового финансирования в форме займов. При этом Руководство никак не предполагает «узкого» подхода при анализе налоговых последствий таких внутригрупповых операций. Речь идёт не только о том, насколько процентная ставка, применяемая по внутригрупповому займу, соответствует «рыночной» ставке, но и о том, что фактически представляет собой полученное финансирование, как доходы от предоставленного финансирования должны распределяться внутри группы с учетом выполняемых функций и принимаемых рисков и т.д.
Так, согласно Руководству, первое, что следует проанализировать, действительно ли операция, оформленная договором займа, является таковой по существу. Российской правоприменительной практике такой подход известен как «переквалификация займа во вклад в уставный капитал»[3]. В связи с этим в новом Руководстве предлагается учитывать следующие критерии заёмных отношений:
Помимо этого, Руководство указывает на те характерные действия, которые осуществляются на этапе принятия решения о предоставлении займа как заимодавцем, так и заёмщиком (анализ рисков, потребности в заёмных средствах, определение суммы, реальной для возврата, анализ иных источников финансирования и т.д.). Эти действия находятся за рамками функций и рисков по самому договору займа, так как предшествуют его заключению. Если согласно документации по ТЦО, либо фактически, вне зависимости от содержания этой документации, характерные для заимодавца действия осуществляет не заимодавец, а, например, региональная штаб-квартира, расположенная в другом государстве, то новое Руководство может быть использовано для обоснования неприменения СИДН со страной «формального» заимодавца. Сумма процентов в этом случае может быть разделена на две части:
Если характерные для заёмщика действия (определение потребности, анализ риска невозврата, поиск альтернативных источников финансирования и т.п.) не осуществляются последним, то заём могут переквалифицировать во вклад в уставный капитал, так как финансирование, фактически осуществляемое без выполнения формальным заёмщиком этих предваряющих функций, характерно для вклада в капитал, а не для займа. Именно при вкладе в уставный капитал вопрос решается акционером по своему усмотрению, согласия общества на такое финансирование не требуется.
Руководство даёт описание различных полезных финансовых функций, которые сотрудники одного предприятия группы, осуществляют в интересах других предприятий группы (например, осуществляемые извне казначейские функции). Руководство в таких случаях основывается на том, что исходя из правил вытянутой руки такая деятельность зарубежной компании группы подлежит оплате внутригрупповыми пользователями. Это может быть использовано:
Кроме того, в новом руководстве специально рассматриваются такие внутригрупповые финансовые операции как:
Многочисленные примеры, иллюстрирующие возможные варианты практического применения подходов, содержащихся в новом Руководстве, позволяют более точно оценить налоговые последствия использования этих подходов в отношении конкретных трансграничных финансовых операций, в которые вовлекаются российские компании.
О чем подумать, что сделать
Российским участникам международных групп компаний следует сопоставить подходы, содержащиеся в новом Руководстве, с тем, как сейчас определяются налоговые последствия внутригрупповых финансовых операций. Новые подходы следует учитывать и при структурировании внутригрупповых финансовых операций на будущее.
Так, следуя подходам, отраженным в новом Руководстве, в отношении операций заемного финансирования имеет смысл:
Помощь консультанта
Юристы «Пепеляев Групп» готовы оказать всестороннюю юридическую поддержку в связи с нововведениями, проконсультировать по всем аспектам нового Руководства ОЭСР по ТЦО для финансовых операций. В частности, мы готовы оказать содействие в проверке финансовых операций с целью выявления несоответствий с подходами, предложенными в новом Руководстве, определения их последствий (рисков) и возможных действий, позволяющих эти риски минимизировать или устранить.
В случаях, когда подобная «проверка» уже была проведена налоговой инспекцией, мы готовы помочь в проведении досудебного и (или) судебного урегулирования спора.
[1] OECD (2020), Transfer Pricing Guidance on Financial Transactions: Inclusive Framework on BEPS Actions 4, 8-10, OECD, Paris
[2] Например, в письме от 24.09.2019 № 03-03-06/1/73272 Минфин, определяя принципы и требования, предъявляемые к порядку подтверждения понесенных внутригрупповых расходов, напрямую применяет Руководство ОЭСР по ТЦО.
[3] Например, Определения ВС РФ от 16.08.2017 № 310-КГ17-10276, от 27.03.2018 № 310-КГ18-1849, от 08.09.2019 № 310-ЭС19-3529.
Первый взгляд на новое программное обеспечение Cisco Firepower Threat Defense (UPD 02.09.16)
Здравствуй, Хабр! Осенью прошлого года мы делились с тобой опытом внедрения сервисов FirePOWER на межсетевом экране Cisco ASA. А в новогодних флэшбэках упомянули про FirePOWER версии 6.0, в которой одной из основных новшеств было управление всеми сервисами с помощью ASDM. Прогресс в Cisco не стоит на месте и этой весной произошел анонс нового модельного ряда Cisco Firepower 4100 и 9300. Это, по сути, все те же модульные ASA, на подобие 5585-X, но с новым названием (привет отдел маркетинга), более навороченные, более производительные и с новым программным обеспечением централизованного управления Firepower Threat Defense (FTD). FTD можно запускать не только на устройствах нового модельного ряда, но и на всех моделях ASA 5500-X, кроме 5585-X (по крайне мере на данный момент). Как раз об этом новом ПО от Cisco и пойдет речь в этой статье.
Немного предыстории. В FirePOWER версии 5.4 все было «просто»: был сенсор, расположенный на SSD ASA (или отдельная железка, или на виртуалке) и было ПО для управления FireSIGHT Management Centre (он же Defense Centre). Для ASA был свой стандартный образ IOS с управлением через CLI/ASDM. Для сенсора нужен был свой образ, доступ на который осуществлялся чрез тот же CLI ASA (или SSH к mgmt-порту). Ну а доступ к FireSIGHT осуществлялся через браузер. К этому нужно добавить отдельные лицензии+смартнет на ASA, отдельные подписки на сенсор и смартнет на FireSIGHT. Само собой, что такой распределенный подход к управлению всеми сервисами не устраивал многих. С выходом FirePOWER версии 6.0 появилась возможность управлять всеми сервисами с помощью ASDM. Ряд ограничений, накладываемый самим ASDM, нехватка централизованного распределения политик по разным сенсорам и несколько других особенностей не всем пришелся по душе, поэтому многим все же приходится ждать полноценного решения для централизованного управления всем и сразу.
С выходом FTD централизованное управление получили – один образ, на котором крутится ПО сенсора и ПО Cisco ASA. Управление и тем и другим происходит через Firepower Management Center (FMC – все тот же FireSIGHT, уже третье название одного и того же, остановитесь, пожалуйста). И все бы ничего, но если в случае с ASDM мы получали ограничения на сервисы FP, то теперь получаем ограничения на функционал и настройку ASA. Основным ограничением является «не работоспособность» VPN. Да и не то что бы он не работал, его просто нельзя настроить штатными средствами. На текущий момент нельзя настроить ни Site-to-Site VPN, ни Remote access VPN.
Образ FTD доступен для установки на всех платформах ASA 5500-X и FP 4100/9300. Не обошлось и без виртуального исполнения – vFTD, на базе которого, в основном, и будет строиться дальнейшее повествование.
Первый образ FTD получил версию 6.0.1. Для того, чтобы можно было подключить FTD к FMC, необходимо обновить FireSIGHT до версии 6.0.1 (требования к FMС не отличаются от требований к предыдущим версиям продукта). Сам же процесс подготовки виртуальной среды или Cisco ASA с последующей инсталляцией образа FTD и его подключение к FMC подробно описан в Quick Start гайдах (VMware, Cisco ASA и на всякий случай Firepower 4100, Firepower 9300), поэтому останавливаться на нем не будем. Тем более, этот процесс для ASA и VMware мало чем отличается от установки отдельного FP сенсора на этих платформах. В конечном итоге картина подключенного FTD (в нашем случае vFTD) будет похожа на такую:
Рисунок 1 – Отображение vFTD в консоли FMC
На что здесь следует обратить внимание:
Лицензии теперь идут по программе Smart License – очередная новая схема лицензирования от Cisco.
Основной посыл этой схемы – это автоматическое отслеживание актуальности подписки/лицензии устройством (устройство самостоятельно периодически спрашивает у Cisco актуальна ли установленная лицензия и соответствует ли настраиваемый функционал условиям подписки) и возможность централизованного управления всеми подписками/лицензиями через созданный под это портал Smart Software Manager.
Рисунок 2 – Smart Licenses для vFTD
2. Routed Mode для виртуального FTD
В отличии от виртуального сенсора FP, vFTD может работать в режиме маршрутизации. Оно и понятно, ведь теперь у нас внутри FTD есть образ ПО ASA. А в случае с виртуализацией его надо на чём-то запускать и это что-то, конечно же, — ASAv, а конкретнее ASAv30. В процессе загрузки vFTD, консоль то и дело пестрит сообщения о запуске ASAv, а то и вообще спрашивает какой образ загрузить:
Рисунок 3 – Загрузка vFTD. Выбор образа для ASAv
Кстати говоря, консоль в момент загрузки vFTD – это единственное место, где можно подсмотреть текущие лицензии на саму ASAv:
Рисунок 4 – Лицензия “VPN Premium” c активированным 3des-aes и без Anyconnect
Раз уж это ASAv30, то с установкой vFTD мы получаем производительность сравнимую с железной ASA 5525-X, судя по цифрам в даташитах вендора (ASA 5500-X, ASAv pdf). Конечно, пока не понятно, какая там производительность с учетом функционала FP, но все же приятно.
Рисунок 5 – Platform Settings для vFTD
В принципе, из названий и так понятно, что за что отвечает, поэтому остановлюсь лишь на одном: на связке External Authentication + Secure Shell/HTTP.
Такая связка нужна для того, чтобы мы смогли попасть непосредственно в консоль ASAv. Создать локальные учетные записи нельзя, поэтому для аутентификации приходится использовать либо LDAP, либо RADIUS (External Authentication). Все вроде бы как обычно: сначала настроить метод аутентификации, а затем с каких адресов, на какой интерфейс и по какому протоколу можно заходить. И если с SSH все отлично, то вот HTTP видимо сделан «на будущее». HTTP на Cisco ASA обычно настраивается для доступа через ASDM, но в данном случае образ ASDM отсутствует на ASAv и опций для его загрузки и настройки в FMC нет, вот и получаем, что при доступе через браузер у нас ошибка 404, а при подключении через ASDM «Unable to launch device manager»:
Рисунок 6 – Подключение к FTD по HTTP
Попав в консоль по SSH, первым делом смотрим show version:
Рисунок 7 – Show version через SSH
Тут и информация по версии vFTD и по софту/железу ASAv. Много Немного поковыряв CLI, приходим к выводу, что создан он с одной лишь целью – мониторинг и траблшутинг. Большинство стандартных команд из категории show ничем не отличаются от таких же команд для «полноценных» ASAv/ASA. Есть команды capture, packet-tracer, debug, test и т.п. Режим конфигурации (conf t) отсутствует. Единственное, что можно настроить из enable режима, – это aaa-server для аутентификации пользователей к этому же CLI. И тут два варианта: либо это ограничения доступа учетных записей, либо такой уж образ ASAv, хотя название для него вполне стандартное (asa961-smp-k8.bin). Но все же внимательно просмотрев выводимую конфигурацию, появляется склонность ко второму варианту, но не без участия первого.
Рисунок 8 – Компоненты классических настроек ASA
Все настраиваемы «объекты» во вкладке Objects создаются с целью дальнейшего их использования различными политиками, в частности политикой, применяемой к устройству во вкладке Device Management.
Настройка политики во вкладке Device Management включает в себя:
Аналогичный при настройке отдельного сенсора FP.
Рисунок 9 – Раздел Devices
Статическая и динамическая (EIGRP, OSPF, RIP, BGP, Multicast). Видимо, за возможность настройки BGP стоит поблагодарить версию 9.6(1) виртуальной ASA.
Рисунок 10 – Настройка маршрутизации
А вот и пример применения «объекта» SLA для статического маршрута и его отображение в CLI:
Рисунок 11 – Пример настройки SLA
Здесь без нюансов и ограничений, доступны все варианты правил NAT.
Рисунок 12 – Настройка правил трансляций
4. Настройка интерфейсов.
Рисунок 13 – Настройка интерфейсов
С интерфейсами все вполне стандартно, за исключением одного момента – привычный всем security-level задать нельзя, все интерфейсы идут с нулевым уровнем безопасности. Но несмотря на то, что в конфигурации отсутствует разрешение на прохождение трафика между интерфейса с одинаковым уровнем безопасности (same-security-traffic permit inter-interface), всё прекрасно работает.
5. Настройка Inline сетов.
Tap mode – вместо того, что бы пропускать весь трафик через сенсор, на сенсор будет попадать только копия трафика, соответственно активные действия по отношению к трафику применяются не будут. Но при этом события (например, события IPS) генерироваться будут. Своего рода режим мониторинга для трафика на выбранной паре интерфейсов («span mode», если сравнивать с отдельным сенсором FP). Propagate Link State – режим bypass, пропускаем весь трафик без проверки, при этом, если один из интерфейсов в паре отправляется в состоянии down, то и со вторым происходит тоже самое (как только проблемный интерфейс возвращает себе состояние up, второй поднимается автоматически). Strict TCP Enforcement – включение контроля тройного рукопожатия для TCP сессий. Tap mode и Strict TCP Enforcement одновременно включить нельзя.
Рисунок 14 – Настройка Inline Sets
6. Настройка сервиса DHCP.
В трех вариантах: DHCP сервер, DHCP релей и DDNS.
Рисунок 15 – Настройка DHCP
На этом, пожалуй, всё. Что же касается параметров классического инспектирования трафика: их изменить нельзя, хотя в CLI они выглядят вполне стандартно с небольшими дополнениями в виде ip опций и дополнительных опций для tcp.
Настройка политик по подпискам (NGFW, NGIPS, AMP)
Настройки всех политик выполняются тем же самым образом, что и раньше. Главное не забывать выбирать необходимое устройство при их развертывании. Интересный момент заключается в политиках NGFW (Access Control Policy) – все настроенные и примененные правила можно посмотреть через CLI. В CLI они отображаются в качестве ACL, который имеет специфическое имя и не менее специфический синтаксис:
Рисунок 16 – Правила Access Control Policy.
И главное здесь то, что такой ACL применяется глобально (access-group CSM_FW_ACL_ global) и более того отсутствие в конце ACL классического правила deny any any, фактически, действительно означает его отсутствие. Весь трафик, который не попадает под созданные правила (в том числе в направлении outside-inside), обрабатывается «действием по умолчанию» (Default Action, рисунок 16). Поэтому, стоит крайне внимательно отнестись к составлению правил, дабы избежать ситуации, когда весь входящий трафик разрешен. Какие-либо нюансы в настройке файловых политик или политик IPS замечены не были.
На первый взгляд версия 6.0.1 FTD показалась крайне «сыроватой», но на то она и первая версия, апдейты не за горами (на момент написания статьи вышел апгрейд до версии 6.0.1.1, включающий в себя ряд багфиксов). На текущий момент, нельзя перенести весь функционал классической ASA на новую платформу и, конечно же, особенно сильно смущает отсутствие VPN. В любом случае, решение на базе ASA FTD хорошо подойдет для ситуаций, в которых необходим исключительно функционал FirePOWER. В любых других ситуациях стоит по-прежнему использовать «раздельный» вариант Cisco ASA with FirePOWER Services. А для тех, кто дочитал до конца (или начал с конца) и всерьез задумался об использовании такого решения (а может уже использует), небольшой «лайфхак» ниже под катом.
Настроить костыльный Site-to-Site VPN можно. Доступ по SSH у нас есть и, да, редактировать конфигурацию мы не можем. Но можем ее загружать – команда copy доступна в полном объеме. Всё, что нам нужно это выгрузить running-config, например, на tftp сервер и отредактировав его, загрузить обратно. Все необходимые строки для VPN можно добавить в разрыв между предпоследней и последней строками конфигурационного файла (Cryptochecksum и end):
Загружать подготовленную конфигурацию нужно командой, с четким указанием расположения конфигурационного файла на FTD:
После того как файл скопируется, SSH соединение оборвется, нужно будет снова подключиться и сохранить конфигурацию (write memory). Выполнив соответствующую конфигурацию на другой стороне, мы получим полноценный, работающий Site-to-Site VPN.
И все бы ничего, но это был бы не «костыль», если бы не один нюанс: созданный таким образом access-list для крипто карты, будет удаляться из конфигурации FTD каждый раз, когда мы применяем любые изменение в консоли FMC (выполняем Deploy). В этой ситуации, к нам на помощь, приходит Embedded Event Manager (EEM), добавленный в ASA с версии 9.2(1). Точно так же, как и с конфигурацией VPN, добавляем в конфигурацию EEM:
Такой EEM будет добавлять каждые 5 секунд в конфигурацию необходимый нам ACL. Так же необходимо добавлять команду привязки ACL к крипто карте, так как удаление ACL из конфигурации приводит и к удалению привязки. Таким образом мы получаем вполне работоспособный VPN.
В такой реализации, стоит ожидать потери пакетов, в моменты развертывания политик с FMC на FTD:
Возможная альтернатива event timer’у в EEM – это выполнение действий при появлении сообщения в логах с конкретным id (event syslog id). Такой вариант не был протестирован, поэтому о его успехе я сказать ничего не могу (даже в случае корректно подобранного id).
Защита компьютера с помощью автономного Microsoft Defender
Автономный Microsoft Defender — это мощный автономный инструмент проверки, который можно запустить из доверенной среды без загрузки ОС. В этом разделе описываются способы использования автономного Microsoft Defender в Windows 10, Windows 8.1 и Windows 7.
В каких случаях следует использовать автономный Microsoft Defender?
Запустите автономный Microsoft Defender, если:
Безопасность Windows (в предыдущих версиях Windows — «Центр безопасности Защитника Windows») обнаруживает на вашем компьютере пакеты программ rootkit или сложно удаляемые вредоносные программы и оповещает вас о необходимости запуска автономного Microsoft Defender. Возможно, появится сообщение о том, что на вашем устройстве обнаружена вредоносная программа, или в системе безопасности Windows появляется сообщение о том, что требуется дополнительная очистка.
Вы подозреваете, что на вашем компьютере есть вредоносные программы, которые скрываются, но программа для обеспечения безопасности не обнаруживает ничего. В этом случае можно запустить проверку компьютера автономным Microsoft Defender, перейдя в раздел «Параметры» меню «Безопасность Windows». Для этого выполните следующие действия.
На экране «Защита от вирусов и угроз» выполните одно из следующих действий:
В последней версии Windows 10: в разделе текущие угрозывыберите Параметры сканирования.
В предыдущих версиях Windows: в области Ж урнал угроз выберите Запустить новое расширенное сканирование.
Выберите Проверка автономного Microsoft Defender, а затем — Проверить сейчас.
Вам будет предложено выйти из Windows. После этого компьютер должен выполнить перезапуск. Загрузится автономный Microsoft Defender, и он выполнит быструю проверку компьютера в среде восстановления. После завершения проверки (как правило, она занимает около 15 минут) компьютер автоматически выполнит перезапуск.
Перед использованием автономного Microsoft Defender сохраните все открытые файлы и закройте все приложения и программы.
Обычно требуются права администратора на компьютере, на котором планируется запустить автономный Microsoft Defender.
При возникновении неустранимой системной ошибки на синем экране во время автономной проверки выполните принудительный перезапуск и попробуйте еще раз запустить проверку автономного Microsoft Defender. Если ошибка на синем экране снова исчезнет, обратитесь в службу поддержки Майкрософт.
Где найти результаты проверки?
Чтобы просмотреть результаты проверки автономного Microsoft Defender:
На экране Защита от вирусов & угроз в Windows 10 в разделе текущие угрозывыберите Параметры сканирования, а затем выберите Журнал защиты (в предыдущих версиях Windows это может сказать История угроз).
Использование автономного Защитника Windows в Windows 7 и Windows 8.1
Примечание: В более ранних версиях Windows автономный защитник Майкрософт по-прежнему вызывается старым именем: автономный защитник Windows
Если вы используете автономный Защитник Windows в Windows 7 или Windows 8.1, выполните эти четыре простых действия.
Скачайте автономный Защитник Windows и установите его на компакт-диск, DVD-диск или USB-устройство флэш-памяти.
Перезагрузите компьютер, используя носитель, содержащий автономный Защитник Windows. Это означает, что компакт-диск, DVD-диск или устройство флэш-памяти, созданное на шаге 1, должно быть установлено в компьютер во время перезапуска. Следуйте указаниям для загрузки с диска, содержащего данный носитель.
Проверьте компьютер на предмет наличия вирусов и других вредоносных программ.
Удалите все вредоносные программы, обнаруженные на компьютере.
Автономный Защитник Windows предоставит пошаговые указания по выполнению этих четырех действий. Если Microsoft Security Essentials или Центр безопасности Защитника Windows предлагает скачать и запустить автономный Защитник Windows, важно это сделать. Это поможет обеспечить сохранность данных и компьютера.
Для начала найдите пустой компакт-диск или DVD-диск либо USB-устройство флэш-памяти, на котором свободно не менее 250 МБ, а затем скачайте и запустите средство по созданию съемного носителя. Вам будут предложены подробные указания для создания съемного носителя.
Примечание: Рекомендуется скачивать автономный Защитник Windows и создавать компакт-диск, DVD-диск или USB-устройство флэш-памяти на компьютере, который не заражен вредоносными программами, поскольку они могут препятствовать созданию носителя.
