После инцидента с Liquid Network на $320 млн: один рубеж пал — что ещё могут защитить платформы цифровых активов?

Недавняя череда инцидентов в сфере безопасности вновь возвращает индустрию цифровых активов к знакомому вопросу: что вообще означает «безопасность» платформы?

В начале сентября на сайдчейне Bitcoin — Liquid Network — произошёл серьёзный инцидент: злоумышленник воспользовался уязвимостью проверки в программном обеспечении Elements, в результате чего было выведено около 4 000 BTC — на момент инцидента это примерно $320 млн. Примечательно, что сами ключи PAK и Federation взломаны не были. Это выводит на поверхность более важный вопрос: если ключи не были скомпрометированы, почему перевод активов, которого не должно было быть, всё же смог пройти через систему?

Похожие риски проявляются и в других звеньях. В августе злоумышленники использовали критическую уязвимость в Cosmos EVM для атак на несколько сетей — в общей сложности шесть сетей подверглись эксплуатации уязвимости, причём об уязвимости ранее уже сообщалось через программу bug bounty. В июле Triple-A столкнулась с атакой с использованием социальной инженерии: злоумышленники получили учётные данные сотрудников и затем проникли в операционную среду, что привело к выводу части собственных средств компании. Однако средства клиентов не пострадали, поскольку хранились отдельно на трастовых счетах и были изолированы от скомпрометированной операционной среды.

Причины трёх инцидентов разные, но все они указывают на один и тот же практический вопрос: полностью избежать инцидентов безопасности, возможно, и нельзя, но когда одно из звеньев — код, люди или права доступа — окажется прорванным, где именно остановится риск?

Защищать нужно не только от «взлома», но и от того, как далеко может распространиться риск

Более важный вопрос, чем «была ли атака», — как далеко может продвинуться злоумышленник после того, как первый рубеж обороны пал? Достаточно ли скомпрометированного аккаунта, чтобы выполнить критически важные операции с активами? Если пробиты права доступа, можно ли продвинуться дальше, к более чувствительным системам? Если что-то идёт не так в онлайн-среде, какая часть ключевых активов действительно оказывается на пути атаки?

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

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

Иными словами, оценивать безопасность платформы нужно не только по тому, «удержится ли первая дверь», но и по тому, сколько ещё дверей останется после того, как первая дверь падёт.

Если смотреть вдоль цепочки атаки — где у BIT находится «следующая дверь»?

Недавно глобальная платформа цифровых финансовых услуг BIT (ранее Matrixport) опубликовала «Белую книгу доверия BIT» V2.0 (https://www.bit.com/whitepaper). Если перечитать этот документ, задаваясь вопросом «что произойдёт после отказа первого рубежа обороны», можно заметить важную особенность: система безопасности BIT не полагается на один-единственный рубеж, а выстраивает многоуровневую защиту между идентификацией, правами доступа, операциями и активами.

Например, получение учётных данных аккаунта ещё не означает, что у злоумышленника есть все права для выполнения критических операций с активами. В белой книге раскрывается, что BIT использует принцип минимальных привилегий, ограничивая системы и операции, к которым могут обращаться сотрудники. Критические операции — перевод активов, операции, связанные с безопасностью аккаунта, изменение прав доступа, создание и проверка торговых поручений — требуют участия как минимум двух уполномоченных лиц. На примере Cactus Custody видно, что такой многоуровневый подход распространяется и на сценарии институционального хранения цифровых активов.

Прохождение аутентификации также не означает, что все последующие операции получают «зелёный свет». BIT постоянно отслеживает аномальные входы, аномальные устройства, аномальные выводы средств; при этом большая часть цифровых активов хранится в холодных кошельках, что дополнительно снижает подверженность ключевых активов риску при проблемах в онлайн-среде.

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

Именно эти «не означает» и определяют, как далеко в итоге сможет продвинуться атака. Это не значит, что любую атаку можно полностью предотвратить, но это значит, что даже при отказе одного рубежа остаётся шанс распознать аномалию, ограничить права или изолировать риск.

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

Когда риск обнаружен — у кого есть право нажать «стоп»?

Но несколько дополнительных технических рубежей — это ещё не всё. В инциденте с Cosmos EVM примечательная деталь: об уязвимости ранее уже сообщалось через программу bug bounty, однако на основании имевшейся на тот момент информации первоначально было решено, что это не приведёт к потере средств в известных конфигурациях production-сетей.

Это вскрывает ещё одну часто упускаемую проблему: обнаружение риска не означает, что риск был точно оценён и надлежащим образом обработан.

После отправки отчёта об уязвимости — кто решает, насколько она серьёзна? Если команда безопасности считает риск неприемлемым, есть ли у неё право остановить дальнейший запуск продукта? Когда бизнес-график вступает в конфликт с оценкой безопасности — у кого остаётся последнее слово?

В «Белой книге доверия BIT» V2.0 раскрывается, что когда в продуктовом решении, требованиях, архитектуре или изменениях, связанных с запуском, существуют значительные риски безопасности, либо когда они не соответствуют базовым стандартам безопасности и комплаенса, команда безопасности обладает «правом вето»: она может приостановить соответствующую деятельность и потребовать исправлений и повторной проверки, прежде чем продолжать.

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

Когда бизнес становится сложнее, «безопасность» — это не только активы в кошельке

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

Именно в этом направлении «Белая книга доверия BIT» V2.0 развивает систему безопасности и доверия. Помимо мер риск-менеджмента и безопасности, в документе раскрываются механизмы регулирования, аудита и независимой проверки для разных бизнес-субъектов, что позволяет внешним сторонам лучше понять: кто за что отвечает, какие механизмы можно проверить и насколько широко они действуют.

Например, в бизнесе BIT, связанном с американскими акциями, бизнес с ценными бумагами ведёт Matrix Gelephu Pte. Ltd., которая находится под надзором GFSO; при этом бизнес подключён к лицензированным финансовым институтам США и соответствующей инфраструктуре клиринга и хранения.

Для обычного пользователя эти кажущиеся сложными финансовые механизмы в конечном счёте сводятся к нескольким простым вопросам: кто обрабатывает мои активы? Через какие звенья они проходят? За что отвечает каждый институт? Можно ли проверить статус и регулирование этих институтов?

Именно в этом и заключается настоящий смысл «проверяемости»: безопасность не может опираться только на слова самой платформы — важно, что пользователи и внешние стороны могут проверить.

Если оглянуться на Liquid Network, Cosmos EVM и Triple-A, у трёх инцидентов совершенно разные точки входа, но все они напоминают рынку: ни один рубеж обороны нельзя считать вечным. Настоящая разница в уровне безопасности, возможно, определяется не отдельной технологией защиты, а способностью выстроить достаточное количество изоляции и сдержек между идентификацией, правами доступа, операциями, активами и организационными решениями, чтобы локальный прорыв было труднее превратить в полную потерю контроля.

С этой точки зрения «Белая книга доверия BIT» V2.0 интересна не только тем, сколько мер безопасности в ней перечислено, но и тем, могут ли эти меры сложиться в целостную систему обороны: если одно звено даёт сбой, остаётся следующий уровень; если и он даёт сбой, остаётся возможность продолжать распознавать, блокировать и изолировать риск.

Для платформ цифровых активов обещание «никогда не подвергаться атакам» вряд ли может стать постоянным. Но другое можно выстраивать постоянно: настоящая безопасность — это когда даже при отказе одного рубежа не позволить одному прорыву легко превратиться в полную потерю контроля. А когда эти рубежи не только существуют, но и могут постоянно проверяться извне, «доверие» перестаёт быть просто словами, которые платформа говорит сама о себе.