AppSECT.A.
378 subscribers
436 photos
9 videos
129 links
Блог Ильи Шмакова

geminishkv.tech

- AppSec Toolchain
- DevOps
- Процессы DevSecOps
- Infosec Risks
- PMI
- Кулуарный ИБ

AppSec Teamlead СберСпасибо @sberbank

Лидер findevsecops.ru @fintechassociation

Преподаватель @bmstu1830, @miptru
Download Telegram
Forwarded from Alexander Popov
Всем привет!

Open source по выходным: я выпустил новый релиз моей карты средств защиты ядра Linux.

Теперь она соответствует относительно свежему ядру v6.17.

Я добавил в нее новые средства защиты, устранил несколько ошибок и сделал связи еще более красивыми 🖼

Радуюсь, что все-таки находятся силы развивать этот проект!

https://github.com/a13xp0p0v/linux-kernel-defence-map
🔥7
Всегда вот смотришь и думаешь, типо топовые, но с кем не бывает, да, правда ведь? 🙃

#lol
🔥5
Жизненное

#lol
🤣8
Forwarded from The Hacker News
⚡AI is making DDoS attacks faster and smarter — helping attackers find weak spots, create new attack vectors, and scale attacks more efficiently.

Watch this WEBINAR to see how it works → https://thehackernews.com/2026/05/new-ai-ddos-attacks-are-smarter-learn.html

What you’ll get:
• Real examples of today’s AI-enhanced attacks
• How to find & fix hidden weaknesses fast
• Practical defenses you can apply immediately
🔥5
🤔 S.T.R.I.D.E. как рабочее решение моделирования и контроля угроз ИБ

Салюты,
Давай сегодня посмотрим на шесть классов угроз описанных в S.T.R.I.D.E. По сути это можно было увидеть во многих выступлениях, но лучше обьяснить смысл и принцип, так как без обвязки он не работает и чтобы превратить её в инструмент нужно DFD и привязка к контролям митигации.

Мы же не живем в идеально иллюзорном мире и всегда приходится что-то куда то "натягивать".

Фундаментом является Data Flow Diagram, как threat modeling с потоками данных, границами доверия. ПО факту это будут у тебя: external entity, процессы, flow, data store, trust boundaries. После только этого ты сможешь перейти к самому S.T.R.I.D.E. Концептуально это все аналитика по принципу:

• Какое свойство Паркеровской гексады нарушается?
• Типовые векторы
• Контроли
• Митигации и оценка рисков ИБ

S.T.R.I.D.E.

• S — Spoofing: подмена, где нарушается подлинность субъекта

Вектора:
• подмена пользователя, session fixation, replay токена
• подмена сервиса, как MITM, фальшивый endpoint, DNS-hijack, отсутствие mTLS между микросервисами
• подмена identity в логах через X-Forwarded-User без проверки

Контроли: MFA, mTLS с проверкой сертификатов, OAuth2/ OIDC с PKCE, привязка токенов, типа DPoP, mTLS-bound, WebAuthn/ FIDO2, anti-replay (nonce, timestamps, jti)


• T — Tampering: фальсификация, где нарушается целостность (data flow (in transit), data store (at rest), процесс (целостность кода и конфигов))

Вектора:
• модификация трафика
• подмена параметров запроса (IDOR через hidden fields, JWT с alg=none, манипуляции client-side state)
• модификация хранимых данных в обход приложения
• supply chain: подмена артефактов сборки, образов, зависимостей

Контроли: TLS актуальных версий, цифровые подписи и HMAC, контроль целостности (checksums, FIM), append-only / WORM журналы, signed commits, signed images, SBOM, контроль конфигураций)


• R — Repudiation (отказ от действий), где нарушается неотказуемость и подотчётность

Вектора:
• пользователь отрицает действие, а доказать нечем
• shared/ служебные аккаунты без идентификации
• админ модифицирует журналы постфактум
• разработчик коммитит без подписи в общую ветку

Контроли: централизованное журналирование с защитой целостности (append-only, WORM), синхронизация времени NTP, корреляция в SIEM, цифровая подпись чувствительных операций, signed commits, запрет shared accounts


• I — Information Disclosure (раскрытие информации), где нарушается: конфиденциальность

Вектора:
• нешифрованная передача
• stack trace и подробные ошибки в ответе пользователю
• BOLA / IDOR — обращение к чужим объектам по перебору ID
• PII (персонификация) и секреты в логах
• side-channel: тайминг, размер ответа, кэш-различия

Контроли: TLS, шифрование at-rest (envelope / KMS / HSM), generic-ответы об ошибках без деталей, output filtering и явные DTO, маскирование PII в логах, минимизация данных, secret management


• D — Denial of Service (отказ в обслуживании), где нарушается доступность

Вектора:
• объёмные DDoS уровней L3/ L4
• application-layer DoS: медленные запросы (slowloris), catastrophic regex backtracking, zip/XML-бомбы, billion laughs
• исчерпание ресурсов: утечки памяти, connection pool, unbounded queues

Контроли: rate limiting и throttling, WAF / DDoS-защита, ограничения размера, времени и глубины, circuit breakers, авто-масштабирование, бэкапы и DR, capacity planning


• E — Elevation of Privilege, где нарушается: авторизация

Вектора:
• BOLA / BFLA: нет проверки прав на объект или функцию
• вертикальная эскалация
• горизонтальная эскалация
• sandbox escape
• JWT-tampering
• RCE через десериализацию

Контроли: RBAC / ABAC с deny-by-default, проверка авторизации на каждом запросе (а не один раз на входе в API-gateway), Segregation of Duties, least privilege, изоляция контейнеров (rootless, seccomp, AppArmor / SELinux), валидация входа, role-claims с клиента


#appsec #devsecops #reco #paper #specialty #riskanalysis
🔥5
Forwarded from The Hacker News
⚠️ WARNING - A malicious npm package was caught stealing files from Claude AI users’ /mnt/user-data directories and uploading them to attacker-controlled GitHub repositories.

Check your installed packages: https://thehackernews.com/2026/05/malicious-npm-package-stole-files-from.html

The package, “mouse5212-super-formatter,” used npm postinstall scripts, hard-coded GitHub tokens, and fake network logs to hide the theft.

Downloaded 676 times so far.
🔥42
"восстание"

#lol
🤣6😱1
Салюты,
Я тут как то забыл сказать, что мне подарили второго котенка, то есть у меня пополнение, а имя у него: Коннор ;) кто в теме, тот в теме
❤‍🔥13
А вот моя первая красотка 🙃
❤‍🔥17
🤔 Риск- и бизнес-ориентированная модель в ИБ

В ГОСТ Р ИСО/ МЭК 15408 и в материалах по управлению рисками всегда описывается одна и таже схема, которая вроде бы выглядит понятно, но все же по ней возникают работы, а обычно мало кто обьяснет принцип ее действия.

Начиная работать по ней в проекте появляется «реестр рисков» без владельцев, без сроков и без связи с реальными активами, что обычная практика на сегодняшний день для многих.

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


Опишем детально

• Активы: данные, сервисы, бизнес-процессы, репутация. Если не можешь оценить ущерб от потери — у тебя не актив, а просто пассив. Пример:
— возможность обрабатывать платежи, база клиентов — активы
— сервера, ВМ, контейнера — носители, не активы
• Владелец: лицо или роль, отвечающее за актив и принимающее решения о его защите, то есть не ИБ и не администратор. Владелец фиксируется вместе с активом и принимает решение принять / минимизировать / делегировать / избежать. Без владельца модель не работает — некому говорить «да, готов жить с этим риском»
• Угроза: потенциальное событие, способное нанести ущерб активу — сценарий, как пример кража токена, вывод средств через скомпрометированную сессию. Угроза — что может случиться; уязвимость — слабость, через которую это происходит. Угроза без актива — абстракция, а без уязвимости — пока не реализуется
• Злоумышленник: субъект угрозы — кто способен и мотивирован причинить ущерб: инсайдер, APT и т.д. Модель нарушителя: категория, мотивация (финансы, разведка, идеология), ресурсы, доступ, потенциал. Без модели нарушителя контрмеры подбираются вслепую — нельзя одинаково защищаться от скриптов и от группировки
• Вектора атак: путь и способ реализации угрозы через уязвимости, такие как - фишинговое письмо, далее макрос, нагрузка и утечка C2
• Уязвимости: слабость, которую может использовать угроза, как пример CVE, процессная (нет триажа), недостаток архитектуры. Уязвимость без угрозы - это гипотеза, а без контрмеры - открытый риск
• Меры минимизации: снижают уязвимости, вероятность реализации угроз или ущерб активу и работает только при правильной настройке, контроле эффективности. Принципы: defense-in-depth и соразмерность. Каждой мере минимизации нужны владелец и метрика, иначе она деградирует
• Риски: возможность реализации угрозы через уязвимость с ущербом для актива. Уязвимость и угроза вместе — потенциал, а риск — его оценка в деньгах, времени, последствиях. Принятый риск без срока и условий пересмотра — это не принятие, а забвение всем нам


Типовые ошибки

• Приравнивание угрозы и уязвимости, в следствии реестр рисков превращается в перечень CVE без сценариев
• Называют активом сервер, а не данные и процессы на нём
• Нет владельца актива и некому принимать решения по риску
• Контрмеры подбирают по аналогии без привязки к конкретной уязвимости или угрозе
• Оценка риска без модели нарушителя, где все угрозы выглядят одинаково вероятными
• Принимаем риск без срока и условий пересмотра
• Контрмеры считают по факту установки, а не по факту работоспособности


Итого

• Следует инвентаризовать активы, назначить владельцев
• Построить модель нарушителя: категория, мотивация, ресурсы, доступ, потенциал (желательно под кейсы, а именно сценарно и не по ФСТЭК России, иначе закопаешься)
• Идентифицировать угрозы по каталогам и привязать к активам
• Выявить уязвимости и связать с активами и угрозами
• Оценить риски по матрице вероятность на ущерб с учётом модели нарушителя и достижимости
• Подобрать контрмеры под уязвимости, зафиксировать ответственных и метрики эффективности
• Согласовать решение по каждому риску с владельцем
• Принятые риски вести со сроком пересмотра
• Пересматривать модель при изменениях


#appsec #devsecops #term #tiskanalysis #pmi #reco #specialty #paper
🔥7
Салют, пока предлагаю изучить тебе эту тему, очень интересно то, что сейчас происходит вокруг RedHat и этого стоит опасаться, на самом деле.

А пока я бегаю тут, готовлю для тебя материалы - это поможет быть нам вместе ближе
🔥4
Forwarded from SecAtor
В результате атаки на цепочку поставок скомпрометированы npm-пакеты в экосистеме Red Hat, распространивших новый вариант вредоносного ПО Shai-Hulud, получившего название Miasma.

Инцидент был обнаружен Aikido и OX Security (1 и 2), которые выявили десятки версий пакетов, содержащих бэкдоры с вредоносным ПО, предназначенным для кражи учетных данных разработчиков, секретов из облачных сервисов, ключей SSH, токенов CI/CD и другой конфиденциальной информации.

По данным Aikido, взломанные пакеты скачиваются примерно 117 000 раз в неделю. Как отметили в Red Hat, затронутые пакеты были удалены после того, как ей стало известно об инциденте.

Скомпрометированные пакеты предназначены исключительно для внутренней разработки, вредоносный код не получил распространения среди клиентов через систему console.redhat.com.

Расследование инцидента продолжается, но, предварительно, влияния на среды клиентов или партнеров, а также на производственные системы Red Hat выявлено не было.

По данным Aikido, злоумышленники, по всей видимости, взломали учетную запись GitHub сотрудника Red Hat и использовали ее для прямой отправки вредоносных коммитов в несколько репозиториев.

Инициированные изменения добавили рабочий процесс GitHub Actions и скрипт, который использовал механизм публикации npm для выпуска пакетов с бэкдорами.

Когда запускался рабочий процесс, он устанавливал Bun и выполнял команду  _index.js, передавая ей список целевых пакетов через переменную среды OIDC_PACKAGES.

Скрипт использует id-token: разрешение на запись для запроса кратковременного токена OIDC от GitHub, затем использует этот токен для прямой аутентификации с доверенной конечной точкой публикации npm и публикации версий каждого пакета из списка с бэкдорами.

Скомпрометированные пакеты содержали вредоносный скрипт предварительной установки, который автоматически запускал сильно обфусцированный вредоносный файл index.js при установке пакетов разработчиками.

Размер полезной нагрузки в файле index.js составлял приблизительно 4,2 МБ и использовался для кражи секретов GitHub Actions, учетных данных AWS, учетных данных Google Cloud и Docker, субъекта службы Azure, токенов HashiCorp Vault, записи службы Kubernetes, публикации npm и PyPI, ключей SSH и GPG и файлов .env.

Исследователи утверждают, что вредоносная ПО, использованная при взломе Red Hat, имеет много общего с Mini Shai-Hulud, но теперь использует строку «Miasma: The Spreading Blight» в качестве комментариев во взломанных репозиториях GitHub.

Вредоносная ПО хоть и напоминает Mini Shai-Hulud от TeamPCP, но неясно, проводилась ли кампания именно этим злоумышленником либо другим, который модифицировал исходный код просочившейся вредоносной ПО.

OX Security полагает, что вредоносная ПО сохраняет ту же функциональность по краже учетных данных, что и Mini Shai-Hulud, но добавляет дополнительные уровни обфускации, многоступенчатые механизмы доставки полезной нагрузки, а также расширенные функции кражи данных и сбора учетных данных.

На текущий момент вредоносной ПО Miasma были скомпрометированы 309 репозиториев GitHub. Установившим затронутые версии вредоносного ПО рекомендуется немедленно обновить все учетные данные, секреты и токены.
🔥4
Простите, но это забавно. «Своровано»

#lol
🤣5😱3
🛠 Коды ошибок и утечка информации через HTTP-методы

Салют, я чет вообще в раздрае, скоро будут прикольные новости, посмотрим как пойдет и что будет.

Сегодня хочу поговорить с тобой о тематике с HTTP-методами, поэтому начнём с того, что DAST — это не только поиск XSS и инъекций, а именно когда приложение само отдаёт конфиденциалку в ответах на кривые или нестандартные запросы.

Пример: GET с избыточной инфой, POST без тела, TRACE — и сервер начинает рассказывать о себе больше, чем должен

Что утекает и откуда

• Коды ошибок — 500 Internal Server Error со stack trace в теле ответа является именем фреймворка, версии, пути к файлам, иногда строка подключения к БД. А допустим 403 Forbidden отличается от 404 Not Found, где мы можем перебором найти закрытые endpoints. А 405 Method Not Allowed прямо говорит, что эндпоинт существует
• Verbose-ошибки в теле — например ASP.NET в режиме разработки отдаёт полный stack trace в HTML. А Spring Boot без server.error.include-stacktrace=never делает то же самое в JSON. К тому же Django с DEBUG=True — отдельная история и очен геморройная
• Заголовки ответа — Server: Microsoft-IIS/10.0, X-Powered-By: ASP.NET, X-AspNet-Version: 4.0.30319 дают нам понимание стека, версии рантайма и саму платформу, то есть самое первое перед эксплойтом
• TRACE-метод — отражает запрос обратно целиком, включая заголовки, где можно увидеть внутренние заголовки, которые добавляет reverse proxy или балансировщик, иногда токены (вот тут я рассмотрел подробнее)


Потыкаем curl


# GET с несуществующим путём — смотрим что в теле ошибки
curl -i https://example.com/api/v1/doesnotexist123

# POST без тела и Content-Type — триггерим ошибку парсинга
curl -i -X POST https://example.com/api/v1/orders

# POST с кривым JSON — часто вытаскивает stack trace
curl -i -X POST https://example.com/api/v1/orders \
-H "Content-Type: application/json" \
-d '{"broken json'

# TRACE — проверяем включён ли метод
curl -i -X TRACE https://example.com

# Смотрим только заголовки — ищем Server, X-Powered-By, X-AspNet-Version
curl -s -D - https://example.com -o /dev/null | grep -iE \
"server:|x-powered|x-aspnet|x-generator|x-runtime"


Что видим?


# verbose error с деталями стека
HTTP/1.1 500 Internal Server Error
X-Powered-By: ASP.NET

{
"message": "Object reference not set to an instance of an object",
"stackTrace": "at ProjectQueryRepository.GetById(Int32 id)\r\n
at C:\\inetpub\\b2b\\src\\Repositories\\ProjectQueryRepository.cs:75"
}

# TRACE отражает запрос обратно
HTTP/1.1 200 OK
TRACE /api/test HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGc... ← токен в отражении

# А вот тут ничего лишнего
HTTP/1.1 500 Internal Server Error

{ "error": "Internal server error", "requestId": "a3f9c2" }


Итого

• 500 с телом ошибки — первое что проверяет DAST
• Разница между 403 и 404 на закрытых эндпоинтах — это enumeration, несуществующее и недоступное должны быть неразличимы снаружи
• Server: и X-Powered-By: убрать на уровне nginx/ IIS — они не нужны клиенту
• Единственное что отдаём при ошибке — requestId, всё остальное во внутренние логи прячем
• Всплески 500 и нестандартных методов — детектируемый паттерн активного поиска
• Единообразие кодов ответа - несуществующий ресурс и ресурс, к которому нет доступа, должны быть неразличимы снаружи — оба возвращают 404
• Server:, X-Powered-By:, X-AspNet-Version:, X-AspNetMvc-Version:, X-Generator:, X-Runtime: убирать на уровне веб-сервера или reverse proxy, так как не несёт никакой ценности при бизнес функции
• Сделать Whitelist разрешённых методов: GET, HEAD, POST, PUT, DELETE, PATCH в зависимости от API, сам TRACE отключается везде
• Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options и остальные заголовки безопасности — отдельный слой, который закрывает эксплуатацию даже если часть информации всё-таки утекла. Без них утечка версии фреймворка в связке с известным CVE и отсутствием CSP превращается в цепочку за один шаг


#appsec #devsecops #reco #specialty #dast
🔥7
А еще жалуются на рождаемость 😅🙃

#lol
🤣8
Я должен поделиться этим 😅

#lol
🤣8❤‍🔥3
🛠 Terrascan IaC policy для конфигураций

Инструмент анализирует шаблоны инфраструктуры как кода (IaC) и проверяет их на соответствие встроенным политикам безопасности. Сканирует конфиги HCL, YAML и JSON, на предмет ошибок, недостаток архитектуры, нарушений практик и проблем с соответствием требованиям.

Основной маппинг на CIS Benchmarks, NIST, SOC2, GDPR, HIPAA из коробки.


Метаданные: Apache 2.0. Форматы отчетов: CLI, JSON, YAML, XML, JUnit-xml, SARIF. Поддерживает Terraform, Kubernetes, Helm, Dockerfile, CloudFormation и т.д. Содержит предопределенные политики для провайдеров: AWS, Azure, GCP, Kubernetes и Docker. Политики написаны на Rego (Open Policy Agent), что позволяет создавать собственные правила.


# Сканирование текущей директории с автоопределением типа IaC
terrascan scan
 
# Сканирование с указанием типа IaC и облачного провайдера
terrascan scan -i terraform -t aws
 
# Вывод результатов в формате JSON
terrascan scan -o json
 
# Фильтрация по severity
terrascan scan --severity "High"
 
#Dockerfile
terrascan scan -i docker
 
# Отображение уязвимостей в образах, упомянутых в IaC-файлах
terrascan scan -i terraform --find-vuln


Типовые находки



# root пользователь
FROM node:18
COPY . /app
RUN npm install
CMD ["node", "server.js"]

# ADD на extrnl URL
ADD https://example.com/script.sh /tmp/


Кастомная политика для обазов без явного тега версий



# policy/no_latest_tag.rego
package accurics.docker.image.latest

deny[msg] {
input.type == "dockerfile"
instruction := input.instructions[_]
instruction.cmd == "from"
contains(instruction.value, ":latest")
msg := sprintf("Image uses ':latest' tag: %v", [instruction.value])
}


CI/CD интеграция



terrascan:
image: tenable/terrascan:latest
stage: security
script:
- terrascan scan -t terraform -d ./infra -o sarif > terrascan.sarif
- terrascan scan -t docker -f Dockerfile -o json > docker.json
artifacts:
reports:
sast: terrascan.sarif
allow_failure: false # блокируем pipeline при HIGH/CRITICAL


pre-commit hook



# .git/hooks/pre-commit
#!/bin/bash
terrascan scan -t terraform -d . --severity HIGH --exit-code 1
if [ $? -ne 0 ]; then
echo "BLOCKED: Terrascan found HIGH/CRITICAL violations"
exit 1
fi


Итого:

• Единый IaC для Terraform, Kubernetes и Helm из коробки
• Возможность написания кастомных правил на Rego для внутренних требований
• Инструмент анализирует код до его развертывания и не отслеживает runtime-угрозы в работающей инфраструктуре. Параметризованные ресурсы проверяются по тому значению, что видно в конфиге
• Подходит больше для кластеров Kubernetes и связанных с ними технологий
• Можно указывать, какие правила игнорировать (--skip-rules)
• Позволяет настраивать критерии QG исходя их severity


#appsec #toolchain #devsecops #sast #techsolution
🔥8😱1
Жиза от РП/ПМ 😅😁

#lol
🤣8
🤔 MultiSig для blockchain: реальный кейс

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

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

Задача: необходимо обеспечить безопасность 800+ BTC в день проходящих через криптопул. Без seed phrase на одном устройстве, без единой точки отказа, без возможности вывести всё одной скомпрометированной подписью.


Как устроена транзакция

BTC на адресе всегда тратится целиком — разбивается на несколько исходящих адресов, остаток уходит на новый адрес (change output), разница между входящей и исходящей суммой — комиссия. Адрес содержит хеш в цепи и позволяет разрешить трату конкретных coin. Мультиподпись меняет этот хеш: вместо «одна подпись» становится «M из N подписей»

Схемы M-of-N

• 2/3 — горячий кошелёк биржи. Биржа держит один ключ, второй резервный, третий — у команды кибербезопасности. Для подтверждения транзакции нужно минимум два. Security-команда подписывает только после проверки на AML и kill-switch
• 3/5 — кошелёк с низким уровнем доверия. Тратить могут любые трое из пяти владельцев. Инициировать перевод может любой, но исполнить — только при достижении необходимого количества подписей. Снижает одновременно три риска: растрату одним участником, взлом, потерю доступа
• 2/3 — эскроу схема. Покупатель, продавец, арбитр. В норме сделка закрывается подписями двух сторон без арбитра. При споре — арбитр подписывает в пользу одной из сторон. Платформа физически не может забрать деньги в одностороннем порядке


Решение для кейса — как это реализовано на практике?

• Схема подписи: 2/3 с разделением ролей — автоматический сервис подписывает рутинные выплаты, security-ключ изолирован и подключается только для нестандартных операций или крупных выводов выше порога AML
• Проверки перед подписанием: валидация адреса получателя по whitelist, проверка суммы, проверка что change output возвращается на наш контролируемый адрес, а не уходит куда-то третьему
• Хранение ключей: hot key в HSM на сервере, backup key offline в физически изолированном хранилище, security key у команды ИБ с hardware token PKCS#11 (на то время). Никаких seed phrase в plaintext, никаких ключей в ENV переменных
• Мониторинг: каждая подписанная транзакция логируется с метаданными — кто подписал, в какое время, сумма, адрес получателя. Алерт при подписании выше порога и иные проверки AML


Почему это важнее чем кажется?

• Большинство взломов — это не взлом блокчейна, а компрометация одного ключа: утечка из ENV, взлом сервера, инсайдер и тд. Поэтому Multisig переводит вопрос в плоскость скомпрометируй M из N одновременно — это принципиально другой уровень атаки
• Для финтех-продуктов это ещё и архитектурный аргумент: если платформа физически не может подписать транзакцию в одностороннем порядке — это не только безопаснее, но и юридически чище в плане ответственности

Итого (полный кейс с разбором транзакций и схемами почитай тут)

• Multisig — не фича, а архитектурный принцип: M из N владельцев должны согласовать операцию
• 2/3 — минимальный разумный порог для горячего кошелька с реальными деньгами
• 5/7 - рекомендуемый порог для холодного хранения и распределения средств с нод
• Разделение ролей, как автоматический сервис/ security/ backup снижает и операционный, и риски ИБ одновременно
• Whitelist адресов с пороговыми проверками, подключенными к мониторингу являются независимыми слоями поверх самой мультиподписи
• Скомпрометировать один ключ при схеме 2/3, а особенно Эскроу - проблематично


Сноска

• Хеш адреса (locking script) — каждый непотраченный выход транзакции защищён условием
• M-of-N (пороговая подпись) — схема где N — общее количество участников с ключами, M — минимальное количество подписей для совершения операции
• Эскроу (escrow) — механизм условного хранения: средства блокируются у нейтральной третьей стороны до выполнения условий сделки


#devsecops #pmi #reco #research #pmcases #techsolution #term
🔥7