HighLoad++ 2013 Iosif Itkin Anton SitnikovIosif Itkin
Система для выявления манипуляций в условиях высокочастотной биржевой торговли
Основная задача системы мониторинга и контроля биржевой площадки — обеспечивать упорядоченное и стабильное функционирование рынка и, в частности, поддерживать аналитическую работу отделов, отвечающих за выявление возможных манипуляций.
Система мониторинга должна собирать информацию обо всех входящих заявках, ответах системы, данных, поступающих из внешних источников, а также о релевантных внутренних состояниях трейдинговой платформы. В условиях высокочастотной торговли объемы этой информации достаточно велики, и их обработка требует масштабируемой инфраструктуры.
Операторы биржевых площадок и участники торгов ожидают, что системы мониторинга и контроля рисков будут оказывать минимальное влияние на основную функциональность трейдинговой платформы и время отклика.
Недобросовестные участники рынка пытаются скрыть злоупотребления и манипуляции рынком под видом легитимных финансовых транзакций, а некоторые законные операции обладают многими признаками нарушений. Системам мониторинга и контроля рынков приходится делать аналитические заключения под высокой нагрузкой, на основе нечеткой логики, параметры которой приходится непрерывно адаптировать под новые трейдинговые ситуации и схемы поведения участников торгов.
Наш доклад содержит обзор предметной области и основных требований к системам мониторинга и контроля для биржевых площадок, а также описание разрабатываемой нами системы, ее архитектуры и выбранного технологического стека, включая Akka, LevelDB, Play, ZeroMQ и ExtJS.
HighLoad++ 2013 Iosif Itkin Anton SitnikovIosif Itkin
Система для выявления манипуляций в условиях высокочастотной биржевой торговли
Основная задача системы мониторинга и контроля биржевой площадки — обеспечивать упорядоченное и стабильное функционирование рынка и, в частности, поддерживать аналитическую работу отделов, отвечающих за выявление возможных манипуляций.
Система мониторинга должна собирать информацию обо всех входящих заявках, ответах системы, данных, поступающих из внешних источников, а также о релевантных внутренних состояниях трейдинговой платформы. В условиях высокочастотной торговли объемы этой информации достаточно велики, и их обработка требует масштабируемой инфраструктуры.
Операторы биржевых площадок и участники торгов ожидают, что системы мониторинга и контроля рисков будут оказывать минимальное влияние на основную функциональность трейдинговой платформы и время отклика.
Недобросовестные участники рынка пытаются скрыть злоупотребления и манипуляции рынком под видом легитимных финансовых транзакций, а некоторые законные операции обладают многими признаками нарушений. Системам мониторинга и контроля рынков приходится делать аналитические заключения под высокой нагрузкой, на основе нечеткой логики, параметры которой приходится непрерывно адаптировать под новые трейдинговые ситуации и схемы поведения участников торгов.
Наш доклад содержит обзор предметной области и основных требований к системам мониторинга и контроля для биржевых площадок, а также описание разрабатываемой нами системы, ее архитектуры и выбранного технологического стека, включая Akka, LevelDB, Play, ZeroMQ и ExtJS.
Презентация с вебинара "Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого было спросить"
Ссылка на страницу вебинара (и запись) - http://solarsecurity.ru/analytics/webinars/665/
Информационная безопасность на базе open source: есть ли смысл?Aleksey Lukatskiy
Анализ возможности перехода на open source решения в контексте кибербезопасности, а также рассмотрение возможных рисков этого и способов управления ими.
Загрузить запись вебинара можно здесь: https://www.owox.com/c/1l9
На вебинаре вы узнаете:
➤Как оценить текущие возможности аналитики в компании и определить зоны «провисания».
➤Как выявить требования к системе сквозной аналитики и разработать целевую модель.
➤Как поэтапно внедрить систему сквозной аналитики с расчетом эффекта для бизнеса.
➤Как с помощью продуктов OWOX BI и Google объединить в Google BigQuery все данные, необходимые для сквозной аналитики: действия пользователей на сайте и в мобильных приложениях, расходы на рекламу, доходы, выполненные заказы, звонки и email-рассылки.
➤Истории успеха наших клиентов: как они настроили систему сквозной аналитики и использовали полученные данные для достижения своих бизнес-целей.
Вебинар будет полезен:
Ecommerce и retail проектам, аналитикам и маркетологам.
2. SearchInform сегодня
Офисы во всех ФО России, а также
в Казахстане, Украине, Беларуси, Польше
1600+ клиентов
в 8 странах мира
10лет на рынке
DLP, 20лет в IT
1 000 000+
ПК под контролем
«КИБ SearchInform»
10уголовных дел
выиграно клиентами
против инсайдеров
Екатеринбург, 6 октября 2016#CODEIB
3. С ЧЕГО НАЧАТЬ?
Определить критерии выбора.
Определить основные каналы передачи
информации, которые необходимо
контролировать.
Выбрать 2-3 системы для тестирования.
#CODEIB
ШАГ 1
ШАГ 2
ШАГ 3
Екатеринбург,
6 октября 2016
4. КРИТЕРИИ ВЫБОРА DLP-СИСТЕМЫ
Количество контролируемых каналов.
Наличие, качество и быстрота реакции
техподдержки.
Надежность и скорость работы системы.
Экспертиза, опыт и надежность вендора.
Аналитические возможности.
Цена и стоимость владения системой.
#CODEIB
Екатеринбург,
6 октября 2016
5. КОЛИЧЕСТВО КОНТРОЛИРУЕМЫХ КАНАЛОВ
#CODEIB
КРИТЕРИЙ 1:
В процессе тестирования,
определите каналы, которые
используются для работы, и
каналы для личного общения.
Уточните у вендора политику
лицензирования и возможность
покупки отдельных модулей,
чтобы не переплачивать за
ненужные каналы перехвата.
Екатеринбург,
6 октября 2016
6. КАК БЫТЬ ДАЛЬШЕ?
– канал контролируется – канал заблокирован
Вариант 1 Вариант 2
7. НАДЕЖНОСТЬ И СКОРОСТЬ
РАБОТЫ СИСТЕМЫ #CODEIB
КРИТЕРИЙ 2:
Полноценное тестирование DLP-системы должно
проходить в срок от 2-х недель до месяца, чтобы
выявить все нюансы и проверить надежность ПО.
Сравните объемы перехвата тестируемых систем
под нагрузкой (если объем данных разных систем
разный, значит одна из них пропускает)
Екатеринбург,
6 октября 2016
8. АНАЛИТИЧЕСКИЕ ВОЗМОЖНОСТИ
#CODEIB
КРИТЕРИЙ 3:
Простота и удобство создания политик безопасности.
Информативность отчетов.
Инструменты для проведения расследования.
Наличие полной базы перехвата (только нарушения или вся база?)
Екатеринбург,
6 октября 2016
9. ТЕХНИЧЕСКАЯ ПОДДЕРЖКА
#CODEIB
КРИТЕРИЙ 4:
Качество работы техподдержки, скорость реакции на запрос.
Скорость устранения проблемы.
Возможность выезда специалиста к клиенту.
Помощь при внедрении, настройке и тестировании.
Екатеринбург,
6 октября 2016
10. РАЗРАБОТЧИК
#CODEIB
КРИТЕРИЙ 5:
Набор предустановленных политик безопасности.
Регулярные обновления, устойчивость к кризисным явлениям.
Отраслевые практики.
Наличие представительств в регионах.
Попросите разработчика познакомить Вас с действующим клиентом.
Задайте ему вопросы о стабильности работы системы, возможностях
контроля, плюсах и минусах работы ПО.
Екатеринбург,
6 октября 2016
11. ЦЕНА И СТОИМОСТЬ ВЛАДЕНИЯ СИСТЕМОЙ
#CODEIB
КРИТЕРИЙ 6:
Стоимость лицензий
Стоимость внедрения
Количество людей,
обслуживающих и
работающих с
системой
Стоимость и скорость
техподдержки
Стоимость
получения новых
версий
Екатеринбург,
6 октября 2016
12. ФИНАЛЬНЫЙ ЭТАП #CODEIB
Составить программу и методику испытаний.
Выбрать 2-3 системы для тестирования.
Сравнить результаты по всем критериям.
Выбрать идеальную DLP по всем критериям ПИМИ.
Екатеринбург,
6 октября 2016