FinTech. А что защищать?

    Всем привет,

    Минутка деанона, меня зовут Анатолий Маковецкий, я Security Team Lead в Exness.

    Сразу извинюсь перед теми, кто ожидает увидеть технический write-up, здесь его не будет. Также в материале описаны настолько очевидные на первый взгляд вещи, что даже не факт, что они являются таковыми, но вы резонно можете меня спросить, как меня наняли и когда я уже перестану притворяться безопасником (ответ на картинке под катом).



    Погнали.


    Изображение: Telegram канал Information Security Memes (https://t.me/infosecmemes)

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

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

    Да, правильно, настоящая информационная безопасность зиждется на процессах, ISO, 27k в зубы и пошли выносить мозги ИТ и топ-менеджменту, все расскажем, все разложим, обоснуем и покажем, никто не поспорит, ведь, надо, только станут ли наши процессы в полях лучше от внедрения очередного стандарта?

    На самом деле посыл в том, что нужно стараться перейти к корневой идее, к комплексной и сбалансированной защите ценных для бизнеса активов, а не к “латочному ремонту” безопасности, а то выглядеть это будет так:


    Фото: s.66.ru

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

    крайне редко безопасность бывает в компаниях сбалансированной, причем часто вопрос не в ресурсах, а в том, что у нас в головах, ну и головах наших ближайших менеджеров:

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

    Оба подхода имеют свои положительные стороны, так как недостаточное внимание к каждой из них порождает свои отдельные риски, но правда в балансе, иначе получается безопасность ради безопасности где-то рядом с тем самым сферическим конем в вакууме. Здесь мы подошли к одной очередной очевидной очевидности:

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

    Примечание: *
    Да, я считаю, что неуязвимых систем не существует, все сводится к сложности эксплуатации и требованиям к компетенциям.

    Часто мы опираемся на чужой опыт, на чужие приоритеты, о которых где-то прочитали, которые не всегда неверные и неподходящие, но часто достаточно не оптимальные для конкретных условий, из разряда Quick Start, что порой, все же, может оказаться оправдано, когда кругом перекати-поле и коршуны кружат, и явно лучше, чем ничего, но бизнес тем временем живет сам по себе.

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

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

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

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

    Давайте на минутку уйдем в сторону и представим себе общий процесс моделирования угроз, как вижу его я:

    1. Мы определяем ценные активы компании, а ценные это те, нарушение свойств которых ведет в конечном итоге к потерям, по опыту, которые в итоге сводятся к финансовым прямо или косвенно, если речь о коммерческой компании. Здесь у нас, как правило, получается та или иная информация, которую мы должны защищать из собственного интереса или по причинам регулирования. Не довелось мне работать на золотых приисках, может, там и не информация на первом месте.
    2. Ранжируем те самые ценные активы, чтоб хоть как-то расставить приоритеты.
    3. Определяем системы, в которых эти ценные активы обрабатываются и хранятся, а в современной компании, как правило, все обрабатывается автоматизировано, в информационных системах (а то, что кто-то из работников может утащить фикус с подоконника, да пачку кофе с общей кухни, тут смело пренебрегаем, плохо, но масштаб не тот).
    4. Ранжируем системы по степени влияния на свойства тех самых ценных активов.
    5. Определяем процессы, которые влияют на наши ценные активы, и, вероятно, реализуются в системах, которые мы определили выше, хотя не всегда.
    6. Ранжируем процессы по степени влияния на активы и бизнес в целом.
    7. На стыке получаем связи активов с системами и процессами, понимаем**, что защищать и в какую очередь.

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

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

    “В финтехе есть деньги”.

    Деньги есть в любой компании. Любая компания, как минимум, рано или поздно платит работникам зарплату, арендует офис, ведет какую-то хозяйственную деятельность и обеспечивает работой бухгалтерию, но сводится это к наличию счета в банке, либо, в дополнение к платежной системе, интегрированной с веб-сайтом, но в финтехе есть реальные деньги, при этом с ними работают внешние пользователи, а добрая часть операций над ними автоматизирована. Упс…

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

    На изображении ниже схема информационных потоков одного из наших продуктов :)


    Изображение: сериал “DuckTales” Walt Disney Television Animation

    Также уход от парадигмы, что мы защищаем только информацию, позволил понять еще один тип ценных ресурсов, которым я пренебрегал ранее, но он присутствует у всех, хотя и является довольно неоднозначным — взаимоотношения, которые могут быть партнерскими отношениями с поставщиком клиентов/трафика, либо с провайдером услуг связи/сервиса безопасности/инфраструктуры. Конечно, раньше я всегда неявно рассматривал это, но в контексте реализации угрозы в вакууме, из разряда Business Continuity Plan и Disaster Recovery Plan, а здесь оно трансформировалось в сознании во вполне осознанный актив, который стоит идентифицировать и защищать, что расширяет наше покрытие, так как мы начинаем двигаться в этом отношении не только от известных угроз, но и от самого актива, как от объекта потенциально подверженного неизвестным угрозам, но не об этом сейчас.

    Если посмотреть ближе, то деньги виднеются со всех сторон:

    1. Как минимум, есть все та же хозяйственная деятельность, как и в любой другой компании.
    2. Есть продукты, которые связаны с финансовыми операциями и со скоростью их проведения, в которых заложена реальная логика входа и выхода денежных средств, то есть деньги не получится убрать в дальний сейф и давать посмотреть на них только раз в сутки после специальной церемонии с “поклонами” и полным “раздеванием”. Их нужно гонять в системах, и чем быстрее, тем, зачастую, лучше для бизнеса.
    3. Есть огромная куча различных платежных систем и других инструментов, у каждого из которых свои реализации взаимодействия, ограничения и особенности интеграции.
    4. Есть инфраструктура, в которой продукты работают.
    5. Есть инженеры, которые делают продукты; инженеры, которые сопровождают продукты; инженеры, сопровождающие инфраструктуру; финансисты, которые имеют доступ к какой-то части финансовых процессов и многие другие.
    6. Есть сами процессы, которые идут через разные системы и команды.

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

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

    То есть в случае с Интернет-банкингом или крипто-кошельками у вас есть креды/секреты/ключи для доступа к ним (обобщим словом “секреты”). Секреты это информация, но есть еще процессы, процедуры и церемонии по работе с ними, ну и относительно потенциально узкий круг лиц для работы с ними. Здесь тоже концепция защиты информации не ломается, но когда мы переходим к стадии прохождения платежной логики прямо или косвенно через все вокруг, а также к “размазыванию” денег по разным продуктам и системам, то ситуация становится куда более tricky :)

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

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

    Если этот материал не провалится по полной, то дальше постараюсь более подробно и практически-ориентированно раскрыть основные подходы, “инструменты” и субъективное видение таких тем, как:

    • Мой “велосипед” на тему моделирования угроз (если будет спрос на него, так как велосипедов и без моего хватает);
    • (Не)доверие и безопасность;
    • Bug Bounty, как мы это делаем и к чему стремимся;
    • Замечания об особенностях русскоязычного рынка ИБ-специалистов после длительного опыта в качестве интервьюера;
    • Что должно драйвить безопасность.

    Если материал зашел — плюсуйте, если провал — топите в комментариях. Всегда рад конструктивному фидбеку, будь он позитивный или нет.

    Всем добра и сбалансированного профессионального подхода!
    Exness
    Финтех-компания, признанный лидер индустрии

    Комментарии 7

      0
      Интересно и по делу!
      Кармы на плюсик нету, не обессудьте! )))
        0
        Спасибо, не плюсов ради :)
        0
        Спасибо за материал.
        Может я упустил, но кмк начинают с того, а кто собственно наш противник. Отсюда появляется бюджет на ИБ, который уже тратится по Вашему плану. С противником главное не заиграться, но и нельзя недооценить. Хотя бюджет отрезвит ретивых руководителей.
        От себя добавлю, что чаще всего встречал проблемы на границе систем в обмене данных. Два отличных приложения работают прекрасно по отдельности, а вот как одно в другое — и все. А еще человеческий фактор тут как тут.
        По-хорошему, надо сделать взлом экономически невыгодным. Но если именно за вас взялись, то взломают все равно.
          0
          Благодарю за развернутый комментарий!
          Да, все абсолютно верно.
          Что касается противника, под вторым спойлером (**), как раз, было небольшое примечание, что деталями в этом материале умышленно пренебрегаю, т.к. описание полного подхода к моделированию и расстановке приоритетов привело бы к сильному увеличению размера статьи, и ее просто было бы невозможно прочитать. Если есть интерес к деталям, то постараюсь подробнее изложить все в отдельном материале. Если вкратце, то противников много, порой и мы сами себе, явно того не замечая, главное, хорошо осозновать собственные возможности и доступные ресурсы при выборе того или иного подхода.
          0
          Хороший пост, жду продолжения. Во многом, это про связь ISO 27k с ISO 9к — когда в компании уже четко определены процессы дающие итоговую прибыль, и понятно что важно, понятно что нужно защищать (на ИБ вопрос только как). Наверно, это не совсем правильно, когда специалист по безопасности выступает и в роли бизнес-аналитика — но это действительно реальность.
            0

            Деньги ещё не самое страшное. Самое страшное — это платёжные реквизиты и история списаний и зачислений. Вообще, я бы разделил:


            1. есть деньги пользователей,
            2. есть информация об этом,
            3. есть информация о том, откуда они получены и как пользователи их тратят (тут зависит от организации, конечно: у кого–то больше точек вывода, у кого–то меньше; чем меньше, тем спокойнее) и
            4. может быть информация о том, почему пользователь получает/тратит деньги именно так. В худшем случае окажется, что мы храним информацию о состоянии здоровья.
              0
              Тут, возможно, мне стоит радоваться, что подробной аналитики по пользователям у нас нет, поскольку мы не являемся платежной системой с развитой экосистемой ритейл-сервисов, а все наши продукты построены преимущественно вокруг действий пользователей с деньгами и над деньгами.
              И опять же, информация о здоровье — это все та же информация, которую еще нужно злоумышленнику монетизировать или проэксплуатировать иным образом, а раскрытие подобной информации приводит к косвенному ущербу, т.е. прямой еще может не наступить, а в случае с финансовыми системами мы получаем сразу прямой ущерб без лишних условностей.

              Вот еще пара хороших примеров, когда информационная безопасность слегка выходит за приделы «информационной»:
              — медицинское оборудование для жизнеобеспечения, которое может удаленно управляться, соответственно реализация угрозы ведет к нанесению прямого вреда объекту, а не к косвенному, как могло бы быть при доступе к медицинской информации о нем (истории болезни, состоянии здоровья и т.п.);
              — SCADA и промышленный IoT, тут также реализация угрозы может привестви к возможности управления защищаемым объектом, а ее эксплуатация — к нанесению вреда обществу и окружающей среде.

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

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое