Риски

Потребность в оценке защищенности ИТ-инфраструктуры появилась практически одновременно с компьютерными системами. В 50-е годы прошлого столетия ученые начали предполагать, что на компьютерные системы возможны атаки, а в 1988 году Робертом Моррисом младшимбыл создан первый массовый сетевой червь, который по скромным оценкам нанес ущерб в 96 млн долларов. Тогда общественность всерьез задумалась над угрозой компьютерных атак.

В 1992 году появился первый документ, содержащий правила управления ИБ в компании, который впоследствии превратился во всем известный ISO/IEC 17799. На основании этого документа стали проводиться аудиты для выявления несоответствий. Вот только аудиты эти помогали убедиться, что системы обеспечения информационной безопасности в компании соответствуют установленным на бумаге (в политиках, регламентах) требованиям, а не защищают от реальных киберугроз. Причем сама проверка проводилась преимущественно в форме опроса сотрудников.

Спустя десять лет появилась методология оценки рисков, которая направила сообщество на путь поиска инцидентов, которые могли бы произойти, и выявления наиболее подходящих путей их предотвращения.Вначале оценка рисков происходила опять же только на бумаге, но затем эксперты стали проводить практический анализ защищенности информационных систем и тестирование на проникновение, для того чтобы корректно верифицировать риски.

Тестирование на проникновение (пентест) это проверка возможности получения злоумышленником несанкционированного доступа к ИТ-ресурсам компании. Пентестеры ищут уязвимые места в системе и демонстрируют возможность проведения атак, моделируя действия хакеров. Формальной эту проверку уже не назовешь. Однако у современного пентеста есть существенный недостаток: он всегда ограничен списком ресурсов, которые можно ломать, но самое главное он ограничен в сценариях поведения атакующих из-за невозможности влиять на реальную инфраструктуру. Есть перечень действий, которые для пентестеров под запретом, как правило, он прописан в договоре. Например, нельзя переводить миллиард с банковского счета, даже если есть такая возможность, или останавливать турбину на теплоэлектростанции.

Эти запреты связаны с тем, что компании боятся необратимости последствий, вызванных моделированием кибератак. Из-за этих ограничений пентест, как правило, заканчивается либо проникновением в локальную сеть компании, либо получением доступа к учетной записи администратора домена. И все. Только демонстрация гипотетических возможностей злоумышленников. И то без демонстрации последствий, ведь доводить атаку до конца запрещено. Это минус для всех сторон: для экспертов ИБ, которые не могут предоставить доказательства своих слов, лишь предполагая, к чему приведут действия хакеров; для службы ИБ компании, которая не может проверить, работают ли меры по противодействию атакующим; для руководства компании, которое может не доверять гипотетическим угрозам.

Еще один недостаток есть во всех перечисленных выше методах. В них не принимается во внимание человеческий фактор: сотрудники службы ИБ не могут оказать сопротивление пентестерам и остановить атаку, а сами пентестеры находятся в тепличных условиях они действуют открыто. Уровень зрелости ИБ в компаниях зачастую невысок, поэтому иногда работа пентестеров и вовсе сводится к подбору учетных данных администратора. В итоге пентестерам сложно развиваться в экспертном плане, им нет смысла совершенствовать свои методы и скрываться от службы ИБ, то есть действовать как реальный хакер, который всегда старается остаться незамеченным. Сотрудники службы мониторинга обычно тоже не принимают участия в пентестах, не анализируют действия пентестеров.

Тестирование на проникновение в режиме Red Team это способ приблизиться к условиям реальной атаки. В рамках Red Team эксперты ИБ имитируют целенаправленные атаки на компанию. В отличие от пентеста служба ИБ оказывает противодействие и тем самым повышает свою готовность к реагированию на киберугрозы. Однако слабой стороной Red Team аналогично пентесту является использование реальной инфраструктуры компании, поскольку вновь невозможно реализовать риск до конца.

Поэтому среди экспертов ИБ так популярны соревнования Capture the Flag (CTF). На CTF-площадках участники могут искать уязвимости в сервисах и использовать их для развития векторов атак на другие команды без негативного влияния на бизнес-функции компаний. Кроме того, эти соревнования отличный способ обучения экспертов ИБ (исследователей, пентестеров, участников Red Team и Bug Hunter). И если раньше бизнес не относился серьезно к CTF, считая это лишь развлечением, то сейчас мы видим, что многие общепризнанные эксперты ИБ, которые теперь занимают высокие должности, когда-то принимали участие в CTF. Правда, соревнования за более чем 20-летнюю историю преобразились.

До 2010 года CTF-соревнования были далеки от реальной жизни и инфраструктуры, уязвимости искусственны, а результат игры неприменим для бизнеса. Есть два формата проведения CTF:

• Task-based, в котором требуется решать отдельные задачи и получать очки за правильные ответы (флаги).

• Attackdefense, в котором участники получают идентичные серверы с набором уязвимых сервисов (приложений), не связанных между собой. Задача каждой команды заключается в том, чтобы найти уязвимости, устранить их на своем сервере и воспользоваться ими для получения конфиденциальной информации (флагов) у соперников.

Во время соревнований участники отрабатывают навыки быстрого поиска и закрытия уязвимостей, они учатся работать в команде, развиваются как эксперты. Сегодня работодатели приветствуют опыт в CTF как для пентестеров, так и для специалистов службы ИБ и SOC. Компании даже сами устраивают соревнования, например Trend Micro с 2015 года, Google с 2016 года. Кроме того, появились публичные программы bug bounty, в которых любой желающий может протестировать сервисы и продукты известных компаний и получить денежное вознаграждение за выявленные уязвимости. Так, за zero-click-уязвимость с исполнением кода на ядре компания Apple готова заплатить 1 млн долларов.

В 2010 году НАТО впервые провела открытые соревнования Locked Shields, в которых столкнулись Red Team (атакующие) и Blue Team (защитники). С 2001 года подобные соревнования под названием Cyber Defense Exercise проводило Агентство национальной безопасности США, но только для учащихся военных академий США. Формат таких соревнований не похож на CTF, это киберучения, эмулирующие реальный мир. В киберучениях применяются ИТ-системы, выполняющие бизнес-процессы, присущие реальным компаниям. Так, в декабре 2020 года Европейское агентство по сетевой иинформационной безопасности(ENISA) проведет Cyber Europe 2020, в котором организаторы смоделируют сценарии, касающиеся здравоохранения.

Движение бизнеса в сторону практической безопасности прозрачной, результативной и обоснованной привело к абсолютно новому формату соревнований. Этим форматом стали киберучения, в которых одновременно могут принять участие все специалисты компьютерной безопасности: пентестеры, исследователи, сотрудники службы ИБ и центра мониторинга. Сценарии атак для киберучений могут быть автоматизированы, а могут реализовываться с привлечением Red Team, состоящей из экспертов ИБ. Привлечение нескольких команд атакующих позволяет улучшить подготовку сотрудников службы ИБ и SOC, поскольку у них появляется возможность проработать больше техник и сценариев атак.

С появлением киберполигона The Standoff у сообщества появилась среда для моделирования кибератак, оценки значимости ресурсов и реализуемости рисков на цифровом макете реального города. В инфраструктуру города заложены живые бизнес-сценарии нефтяной компании, ТЭЦ, подстанции, химического завода, аэропорта, банка, железной дороги, морского порта, а значит, участники столкнутся с настоящим оборудованием и сервисами, используемыми в этих компаниях. The Standoff это уникальная возможность довести вектор атаки до конца и посмотреть, к чему это приведет: будет ли украден миллиард и надолго ли останется город без электричества после выхода из строя паровой турбины ТЭЦ. При проектировании The Standoff были использованы реальные контроллеры, которые используются на идентичных объектах критически значимой инфраструктуры, а значит, у экспертов ИБ есть возможность протестировать сценарии атак до конца. Если атака будет успешной и электростанция остановится, значит, она остановилась бы и в реальной жизни.

С развитием киберполигонов у компаний начинает появляться возможность как можно точнее моделировать собственую инфраструктуру, а значит, оценка рисков и последствий выходит на новый уровень. Пока хакеры совершенствуют свои методы атак, компании повышают уровень зрелости в сфере ИБ и отрабатывают техники реагирования на киберинциденты. Все специалисты компьютерной безопасности от администраторов до пентестеров улучшают свои навыки не в искусственном окружении, а в реалистичной среде, повторяющей и инфраструктуру, и бизнес-процессы компаний. А это значит, что завтра враг уже не пройдет.

Изучить киберполигон The Standoff вживую вы сможете уже завтра 12 ноября. The Standoff стартует в онлайн-формате и продлится в этом году целых шесть дней. Помимо активностей, связанных с кибер-битвой, вы сможете послушать доклады лучших экспертов в области практической кибербезопасности со всего мира: более 30 спикеров из России, США, стран Европы и Азии поделятся с вами своими последними наработками. Для участия в мероприятии достаточно лишь подключиться к онлайн-платформе.

Автор: Ольга Зиненко, аналитики информационной безопасностиPositiveTechnologies

Дано:

1. Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).

2. Заказчик = крупное российское полукоммерческое предприятие. Со стороны Заказчика участвуют 4 департамента (с одинаковым влиянием друг на друга), один из департаментов является функциональным заказчиком (ФЗ) и владельцем бюджета. Остальные отвечают за безопасность и ИТ-сопровождение.

3. Распределенная на 2 города команда со стороны Исполнителя, проблемы с коммуникациями отсутствуют.

Найти:

1. OS-приложение под iPhone с современным интерфейсом и доп. функционалом

Ограничения:

1. Заказчик на момент проекта никогда ранее не работал по Agile-методологиям, но их руководство на основе последних трендов повсеместно пыталось запустить использование Agile;

2. Договорные отношения между Заказчиком и нами были FixedPrice (оформить T&M было невозможно).

Решение:

При инициации проекта между Заказчиком и нами была достигнута договоренность, что все готовы работать в рамках Agile, но с фиксированным скоупом, который был четко ограничен рамками договора. Для удержания скоупа (по лучшим практикам agile) по каждой фичи озвучили условные эстимейты, расставили приоритеты и договорились на берегу, что при возникновении исключений и увеличении скоупа просто обменяем часть требований на другую. В рамках существующих договоренностей и оценок также предполагалось переиспользовать существующее приложение, в котором были реализованы необходимые бизнес-процессы.

Разработка продукта происходила, как и положено, итерациями. Каждая итерация составляла 2 недели: формирование скоупа -> разработка -> тестирование -> демонстрации -> фиксирование замечаний -> формирование скоупа ->

В итоге количество промежуточных поставок составило 18 штук, учтены были все основные пожелания стейкхолдеров и реализован весь необходимый набор требований, последняя поставка была признана релизом с обеих сторон. Приемо-сдаточные испытания (которые из-за бюрократии Заказчика и договора FixedPrice даже в рамках используемого гибкого подхода отменить невозможно) были пройдены без критичных и условно-критичных замечаний с первого раза.

Что было неизменно (для отношений Заказчик-Исполнитель):

1. Постоянное давление статусом Заказчика и уровнем важности его конечных целевых пользователей.

2. Растущие аппетиты Заказчика и жонглирование требований между 4 заинтересованными департаментами. Например, в ходе разработки продукта появилось требование использования библиотек корпоративной MDM-системы для сохранения конфиденциальности данных внутри приложения. Как итог: из-за внутренних противоречий Заказчика было разработано 2 сборки (с поддержкой MDM и без), первый год после внедрения в пром 99% пользователей использовали принципиально версию без MDM-системы все из-за тех же внутренних противоречий между департаментами.

Немного графиков со статистикой растущих аппетитов (цифры про трудоемкости и длительности опущены на графиках из-за NDA компании с Заказчиком):

Почему Agile не помог

В рамках каждой итерации готовились кликабельные макеты приложения, которые детально согласовывали со стейкхолдерами Заказчика (как и учит Agile). Заказчик со своей стороны собрал пилотную группу из будущих пользователей около 10 человек (в которую также входили лица, принимающие решение наверху) для апробации будущего продукта. Согласованные макеты превращались в приложение, и каждый выпуск промежуточной законченной версии продукта позволял пилотной группе пощупать и дать свой фидбек. Все замечания обрабатывались, обсуждались, оценивались, после обсуждения и согласования адекватные замечания исправлялись в следующих итерациях. Все как в лучших практиках.

НО

Как писала выше, после использования лучших практик успешно прошли приемо-сдаточные испытание, начали тиражировать приложение в промышленную эксплуатацию. Во время тиража приложение получил руководитель департамента ФЗ, начал использовать, а мы радостно и весело стали переписывать половину интерфейса приложения, так как гайдлайны Apple ничего не понимают о дизайне корпоративных приложений, и нужно было срочно сделать устаревшие формы экранов из iPad на iPhone.

Выводы или зачем нужна эта статья

Казалось бы, все просто: методологии Agile в своих принципах нацелены на минимизацию рисков путем сведения разработки к серии итераций и постоянному тесному контакту со стейкхолдерами. Не согласовали дизайн приложения и свои многочисленные макеты со всеми заинтересованными стейкхолдерами сами виноваты, у вас было 18 поставок, чтобы спросить ключевого пользователя, что не так.

А еще одно из главных достоинств Agile это отсутствие бюрократии. Только российская действительность и некоторые полукоммерческие предприятия, даже с внедренным у себя Agile, не готовы отказаться от бюрократии и жесткой иерархии в своих структурах, а большие начальники порой не готовы участвовать в проектной работе. Проектные команды могут сколько угодно формировать списки стейкхолдеров, проводить демонстрации и соблюдать все принципы гибких методологий, но не смогут избежать рисков того, что по итогу продукт придется переделывать. А как работать с рисками недоступности стейкхолдеров, да и в принципе как работать с рисками методологии Agile не учат. Потому что это про продукт, а не про риски при его выпуске.

Собственно, возникшую проблему после опытной эксплуатации продукта решали другими методологиями, где подробно рассматривается управления рисками. И как учит туториал Хабра: Неуспешные кейсы тоже полезны, они помогут кому-то не наступать на грабли, на которые другие уже наступали. Не скажу, что мой кейс неуспешен, сотрудники Заказчика пользуются продуктом уже несколько лет, в рамках проекта были достигнуты почти все поставленные цели. Но мой кейс один из примеров, когда нельзя забывать о стратегиях управления рисками в угоду пропаганде повсеместного использования Agile.

Опционы - вид ценных бумаг, вызывающих постоянный интерес даже у начинающих трейдеров. Об опционах написано немало статей, поэтому мы опустим ознакомительную часть и будем считать, что читатель знаком с основными терминами опционной торговли. Если что, то их толкование несложно найти в интернете.

После первого знакомства с теорией у начинающих торговцев опционами возникает вопрос: а при каких условиях данный набор опционов даст прибыль, и какую. Даже опытный опционщик сходу не сможет ответить на этот вопрос, если у вас более одного опциона. Для этого необходим анализ опционного портфеля ( набора опционов и , возможно, фьючерсов), который нагляднее всего делается в графическом виде, на диаграмме зависимости прибыли/убытка от стоимости базового актива. В настоящее время существует несколько сайтов для этого, а также отдельных программ.

Автор статьи реализовал анализ опционов с помощью телеграмм-бота, что дает возможность быстрого получения информации об инвестиционном портфеле на смартфоне.

Будем считать, что, кроме опционов, читатель знаком с телеграмм ботами. Поэтому здесь не будет описания создания бота от получения токена до обработки клавиатуры. Вместо этого перечислим концептуальные проблемы, которые возникли при создании программы, и способы их решения.

Запоминание состояния бота между вебхуками

Бот получает сообщения от пользователя через встроенный в телеграмм механизм вебхуков. Каждый вебхук заново запускает программу, но для каждого пользователя необходим свой набор данных. Идентификация пользователей осуществляется через просмотр потока ввода:

$id_init = file_get_contents('php://input');$id=sbs($id_init, '"from":{"id":',',"is_bot":'); //в эту переменную записываем уникальный номер пользователяfunction sbs ($str,$m1,$m2){ //из строки str возвращает подстроку между двумя метками-словами m1 и m2$p1=strpos($str,$m1)+strlen($m1); //длина слова-метки слева$p2=strpos($str,$m2);return substr($str,$p1,$p2-$p1);}

Для каждого пользователя строится следующая структура данных:

1. файл состояния: переменные флажки , которые описывают в частности, идентификационные номера сообщений ( message_Id) для дальнейшей их редакции, актуальное состояние ( ввод количества, ввод страйка и т.д.), вспомогательные данные для построения графика

2. файл данных по составу портфеля ( идентификационный номер ценной бумаги, тип, количество, цена, дата экспирации)

3. файлы для построения графика

После каждого вебхука происходит инициация данных в программе из указанных файлов.

Построение графика для анализа портфеля

График строится по состоянию на момент экспирации опционов, что дает возможность упрощенно представить график каждого инструмента в виде y=kx+b,

где y это размер прибыли/убытка на момент экспирации

х стоимость базового актива

После записи данных в портфель создаются файлы с расширением png с помощью библиотеки GD в несколько этапов:

1) определение Х-координат всех точек перелома на графике (очевидно, что сумма всех линий даст ломанную кривую)

2) определение масштаба изображения (средняя всех координат точек перелома по оси Х, максимальное отклонение от среднего, и максимальный размер по оси Y)

3) создание ассоциативного массива точек, в котором координата X это ключ, координата Y величина, для всей цифровой полуплоскости:

$typ опцион колл, пут или фьючерс

$q количество ( отрицательное продажа)

$cena цена приобретения ценной бумаги

$strike страйк для опционов

$x0 начальная координата по оси Х

$sx масштаб по оси Х

function pparr($typ, $q, $cena, $strike,$x0,$sx){ //функция выдает одномерный массив - координаты x=>y точек по //типу цб, направлению (покупка продажа), цене приобретения и страйку (для опционов)  if ($q<0) { $q=-$q; $drct='-'; }  else $drct='+'; $a=array(); $b=array(); $delta=$sx; //расстояние между точками равно масштабу $scalx for ($i=0;$i<740;$i++){ //кол во точек 740 определено заранее $xkk=$x0+$delta*$i; //значение по оси X if ($typ=='fut') { if ($drct=='+') $a[$xkk]=($xkk-$cena)*$q; else $a[$xkk]=(-$xkk+$cena)*$q; } if ($typ=='call'){ if ($drct=='+') { if ($xkk<=$strike) $a[$xkk]=-$cena*$q; else $a[$xkk]=$q*($xkk-$strike-$cena);} else { if ($xkk<=$strike) $a[$xkk]=$q*$cena; else $a[$xkk]=(-$xkk+$strike+$cena)*$q;}  } if ($typ=='put'){ if ($drct=='+') { if ($xkk<=$strike) $a[$xkk]=(-$xkk+$strike-$cena)*$q; else $a[$xkk]=-$q*$cena;} else { if ($xkk<=$strike) $a[$xkk]=($xkk-$strike+$cena)*$q; else $a[$xkk]=$cena*$q;}  } $b[(string)$xkk]=(string)$a[$xkk]; }return $b; };

4) создание файлов изображений, при этом одновременно строится график для каждой строки из портфеля ( зеленый цвет) и результирующий для портфеля ( красный цвет). Кроме того, know-how заключается в том, что одновременно строится еще четыре изображения для увеличения/уменьшения изображения по оси Х и по оси Y. За счет этого достигается эффект работы он-лайн с клавишами X+,X-,Y+,Y- под графиком. Таким образом, для каждого пользователя в каждый момент времени существует пять файлов изображения.

Анализ рисков опционного портфеля

В тесной связи с прибыльностью находится понятие риска. В количественном выражении риск по опционному портфелю выражается в сумме так называемого гарантийного обеспечения. Гарантийное обеспечение та сумма, которая списывается со счета трейдера при совершении сделки. Фактически, исходя из данных на текущий момент, блокируется сумма максимального убытка (потерь). Однако, и это самое главное, сумма гарантийного обеспечения, списанная с вашего счета, пересчитывается после каждого клиринга ( утро, обед и вечер). Она может как увеличиваться, так и уменьшаться. При спокойном течении торгов (в пределах какого-то диапазона) вы можете увидеть, что сумма на вашем счете растет за счет уменьшения ГО. Однако, ГО может резко вырасти в экстренных ситуациях ( стихийные бедствия, санкции, войны) и не только в экстренных (праздники) . В этом случае у вас может быть списана дополнительная сумма в рамках увеличения ГО. Если денег на вашем счете не хватит для оплаты увеличившегося ГО, наступает маржин-колл, в рамках которого ваши ценные бумаги будут принудительно списаны по текущей рыночной цене, что ведет к обнулению счета.

В телеграмм-боте встроен блок расчета гарантийного обеспечения, в котором реализован следующий подход.

Гарантийное обеспечение для фьючерсов считается по формуле, которая предложена самой Московской биржей:

ГО=БГО+(Цена-Расчетная_Цена)*БП;

где Расчетная_Цена определяется по результатам клиринга и практически равна цене базового актива на момент клиринга, определяется в пунктах

БП стоимость пункта в рублях, зависит, в частности, от курса доллара,

БГО базовое гарантийное обеспечение, определяется биржей, может произвольно увеличиваться, например, перед праздниками

Таким образом, по фьючерсам ГО считается достаточно просто, поскольку все данные есть в открытом доступе. Что касается опционов и тем более сочетаний их в разных комбинациях, Московская биржа не дает однозначного рецепта, вернее не дает данных для их расчета, а предлагает купить модуль расчета ГО.

В телеграмм-боте предлагается следующий подход: риск по опциону такой же , как по фьючерсу, в той мере, насколько опцион похож на фьючерс. При этом понятно, что нас интересуют только убытки, то есть нижняя полуплоскость нашего графика. Попробуем пояснить с помощью графиков.

Вот как выглядит покупка колла в нашем боте:

Гарантийное обеспечение=23.

Что нам показывает график: если стоимость базового актива ( в данном случае стоимость фьючерса на курс рубля к доллару) [вечером] 03.06.2021 будет 75000 и ниже, то наш убыток составит 23 . При повышении этой стоимости до 75023 мы выйдем в безубыток, при дальнейшем росте получим прибыль.

Что мы имеем с точки зрения риска: не при каких обстоятельствах наш убыток не превысит сумму 23. Следовательно, наш опцион совершенно не похож на фьючерс, и в расчете ГО мы можем записать просто сумму 23.

Покупка пута примерно та же картина.

Продажа пута.

Гарантийное обеспечение= 5436.

Можно убедиться, что при стоимости базового актива выше 72750 мы имеем прибыль 44. При снижении стоимости БА до 72706 мы выходим в ноль. При дальнейшем падении стоимости БА наш убыток НИЧЕМ НЕ ОГРАНИЧИВАЕТСЯ.

С точки зрения рисков это фьючерс, купленный по цене 72706. Подставляем это число в формулу ГО для фьючерса и получаем ГО для опциона! Этот ГО достаточно велик (5436), но может превратится в прибыль в течение нескольких дней.

Стоит ли овчинка выделки? Если при условных затратах сегодня 5436 мы получим через несколько дней 44? Мне кажется, риск очень велик. С другой стороны, курс рубля к доллару был таким примерно 3 месяца назад.

С продажей колла будет аналогичная ситуация.

А если одновременно продать пут и кол?

Гарантийное обеспечение не изменилось!

С точки зрения риска понятно почему может реализоваться только один из сценариев либо по фьючерсу, купленному по примерно по 72700 (левая нога) либо по фьючерсу проданному по 75190 ( правая нога). Из них выбираем вариант

с наибольшим ГО , оно и будет мерилом риска.

На графике можно увидеть, что прибыль мы имеем при стоимости базового актива в диапазоне от примерно 72700 до 75190, в остальных случаях получаем убыток, который ничем не ограничивается.

Интерфейс телеграмм-бота

На экране отображаются следующие группы данных:

• подробная инструкция по работе с ботом

• текущие котировки ближайших фьючерсов по трем базовым активам

• таблица Портфель, отображающая состав портфеля, сделанная с помощью интерфейса телеграмм ( можно редактировать)

• значение гарантийного обеспечения

• таблица, дублирующая состав портфеля, построенная как изображение формата png, которую можно копировать и сохранять

• нижняя клавиатура, которую можно скрывать, с кнопками: Добавить позицию в портфель, Анализ портфеля с помощью графика, Обновить котировки

Таблица Портфель создана с помощью InlineKeyboard.

При нажатии на клавиши в этой таблице происходят следующие действия:

• клавиша в столбце К-во редактирует количество ценных бумаг, соответствующее строке, в которой нажата клавиша

• клавишами в столбце Цена можно ввести реальную цену приобретения ценной бумаги. По умолчанию цена вставляется по данным биржи, и для опционов она может значительно отличаться от рыночной

• клавишей Х можно удалить строку.

Прочие клавиши в таблице заблокированы и служат только для передачи информации.

Значение гарантийного обеспечения пересчитывается каждый раз, когда вы нажимаете кнопку Записать в портфель( не показана, возникает в конце процедуры редактирования или добавления инструмента).

Заключение

В телеграмм-боте реализовано запоминание портфеля ценных бумаг для каждого пользователя. Под ценными бумагами понимаются опционы и фьючерсы, базовым активом для которых являются: курс рубля к доллару (Si), стоимость нефти брент (BR), а также индекс РТС (RI). Это самые высоколиквидные деривативы на московской бирже.

В телеграмм-бот заложен алгоритм подсчета гарантийного обеспечения, которое является мерой риска.

С помощью телеграмм-бота можно анализировать опционный портфель на графике прибылей/убытков (P/L график).

Протестировать телеграмм-бота можно по ссылке t.me/@test09062020bot. Или попробовать найти в телеграмме по названию опционный портфель.