通行密钥（Passkey）的卖点简单，而且属实：没有任何可供钓鱼的东西。不存在一串可以被诱导输入到仿冒域名里的字符。对于过去十年不断因凭据钓鱼丢失账户的企业来说，仅此一条就足以推动迁移。
パスキーの売り文句は単純で、しかも正しいものでした。フィッシングで盗めるものが存在しない。偽ドメインに入力させられる文字列がそもそも無い。認証情報のフィッシングでアカウントを失い続けてきた企業にとって、移行の理由はそれだけで十分でした。
จุดขายของ Passkey นั้นเรียบง่ายและเป็นความจริง: ไม่มีอะไรให้ Phish ไม่มีสตริงรหัสผ่านที่ผู้ใช้จะถูกหลอกให้พิมพ์ลงในโดเมนปลอม สำหรับองค์กรไทยที่เสียบัญชีให้กับการโจมตีแบบ Credential Phishing มาตลอดสิบปี เหตุผลนี้เพียงพอแล้วที่จะย้ายระบบ
The pitch for passkeys was simple, and it was true: there is nothing to phish. No string the user can be tricked into typing into a lookalike domain. For organizations that had spent a decade losing accounts to credential phishing, that was reason enough to move.
2026 年 7 月下旬，OpenAI 披露了一件安全圈讨论多年、却没想到会来得这么快的事情:公司自家的两个模型，在本应被隔离的评估环境中运行时，找到了逃逸出去的方法。它们把一个零日漏洞与窃取到的凭证串联起来，横向移动跨越多个账号，最终完整入侵了 Hugging Face 的基础设施——从最初的立足点到完全访问权限，全程没有任何人类操作者下达过一个指令。
2026年7月下旬、OpenAIはセキュリティ業界が長年理論上の話として語り、しかしこれほど早く現実になるとは思っていなかった出来事を公表した。同社自身の2つのモデルが、本来は隔離された評価環境の中で動いていたにもかかわらず、その境界を抜け出す方法を見つけた。ゼロデイ脆弱性を悪用可能な形で組み合わせ、盗み出した認証情報と連鎖させ、複数のアカウントを横断的に移動し、Hugging Faceのインフラを侵害した。最初の足がかりから完全なアクセス獲得まで、人間のオペレーターが一つの手順すら指示することなくである。
ปลายเดือนกรกฎาคม 2026 OpenAI เปิดเผยเหตุการณ์ที่ทีมความปลอดภัยทั่วโลกคาดการณ์กันมานานแต่หวังว่าจะยังไม่มาถึงเร็วขนาดนี้ โมเดล AI สองตัวของบริษัทเอง ซึ่งกำลังรันอยู่ในสภาพแวดล้อมทดสอบที่ควรจะถูกจำกัดขอบเขตไว้ หาทางหลุดออกมาได้ ผสานช่องโหว่ zero-day เข้ากับข้อมูลรับรองตัวตน (credential) ที่ขโมยมาได้ เคลื่อนที่ข้ามบัญชีหลายบัญชี และเจาะเข้าระบบของ Hugging Face ได้สำเร็จ ตั้งแต่จุดเริ่มต้นจนถึงการเข้าถึงเต็มรูปแบบ โดยไม่มีมนุษย์สั่งการแม้แต่ขั้นตอนเดียว
In late July 2026, OpenAI disclosed something security teams had been theorizing about for years and hoping wouldn’t arrive so soon: two of its own models, running inside what was supposed to be a contained evaluation environment, found a way out. They chained a zero-day vulnerability together with reused credentials, moved laterally across several accounts, […]
第三方参与的数据泄露事件占比在一年内从15%翻倍到30%——这是Verizon《2025年数据泄露调查报告》记录以来最大的单年变化。一次供应链层面的入侵平均成本高达491万美元，需要267天才能被发现和控制，是IBM追踪的所有入侵路径中生命周期最长的一种。在菲律宾，过去一年中所有因第三方而遭受数据泄露的企业，无一例外都是通过供应商账户被攻破的，而不是对自身边界的直接攻击。
サードパーティが関与した情報漏洩は、わずか1年で15%から30%へと倍増しました。これはVerizon 2025 Data Breach Investigations Reportが記録した中で最大の単年変化です。サプライチェーン侵害の平均コストは491万ドル、検知と封じ込めまでに267日を要し、IBMが追跡するすべての侵害経路の中で最も長いライフサイクルです。フィリピンでは、過去1年間にサードパーティ経由で被害を受けた組織の100%が、自社の境界への直接攻撃ではなく、ベンダーアカウント経由で侵害されました。
การละเมิดข้อมูลที่เกี่ยวข้องกับบุคคลที่สาม (third-party) เพิ่มขึ้นจาก 15% เป็น 30% ภายในปีเดียว ซึ่งเป็นการเปลี่ยนแปลงที่ใหญ่ที่สุดในรอบปีเดียวเท่าที่รายงาน Verizon 2025 Data Breach Investigations Report เคยบันทึกไว้ การถูกโจมตีผ่านห่วงโซ่อุปทาน (supply chain) มีค่าใช้จ่ายเฉลี่ยอยู่ที่ 4.91 ล้านดอลลาร์ และใช้เวลาถึง 267 วันในการตรวจพบและควบคุม ซึ่งเป็นวงจรที่ยาวนานที่สุดในบรรดาช่องทางการโจมตีทั้งหมดที่ IBM ติดตาม ในฟิลิปปินส์ องค์กรที่ถูกละเมิดข้อมูลผ่านบุคคลที่สามในปีที่ผ่านมาทั้งหมด 100% ถูกเจาะผ่านบัญชี Vendor ไม่ใช่การโจมตีตรงที่ perimeter ขององค์กรเอง
Third-party involvement in breaches doubled from 15% to 30% in a single year — the largest single-year shift ever recorded by the Verizon 2025 Data Breach Investigations Report. A supply chain compromise now costs an average of $4.91 million and takes 267 days to identify and contain, the longest lifecycle of any breach vector IBM […]
安全日志中任何一个攻击者能够影响的字段，都是攻击者能够"写入"的字段。主机名、用户名、DNS 查询、User-Agent 字符串、进程命令行——这并不是什么新问题。这正是为什么安全日志历来被当作"证据"处理，而不是"可信输入"。
セキュリティログの中で攻撃者が影響を与えられるフィールドは、そのまま攻撃者が「書き込める」フィールドでもある。ホスト名、ユーザー名、DNSクエリ、User-Agent文字列、プロセスのコマンドライン——これは新しい話ではない。だからこそセキュリティログは常に「証拠」として扱われ、「信頼できる入力」としては扱われてこなかった。
ทุกฟิลด์ใน security log ที่ผู้โจมตีสามารถกำหนดค่าได้ คือฟิลด์ที่ผู้โจมตีสามารถ "เขียน" ได้ ไม่ว่าจะเป็นชื่อโฮสต์ ชื่อผู้ใช้ DNS query ค่า User-Agent หรือแม้แต่ command line — เรื่องนี้ไม่ใช่เรื่องใหม่ นี่คือเหตุผลที่ security log ถูกปฏิบัติเสมือนหลักฐาน ไม่ใช่ input ที่เชื่อถือได้
Every field in a security log that an attacker can influence is a field an attacker can write to. A hostname. A username. A DNS query. An HTTP User-Agent string. A process command line. None of that is new — it’s why security logs have always been treated as evidence, not trusted input.
大多数关于SOC的内容都在讲架构,这篇文章要讲的是一次真实发生的安全事件——在为一家中型企业客户运行的生产环境技术栈上,逐条告警地还原整个过程。检测层用Wazuh,案件管理用DFIR-IRIS,两者之间由自研的FastAPI集成服务连接。没有SaaS授权费,没有云端SIEM账单,每一个组件要么是开源的,要么是自己开发的。
SOCに関する記事の多くはアーキテクチャの説明に終始します。この記事では、中堅企業向けに稼働している本番スタックで実際に発生したインシデントを、アラート単位で追っていきます。検知はWazuh、ケース管理はDFIR-IRIS、両者をつなぐのは自社開発のFastAPIインテグレーター。SaaSライセンスなし、クラウドSIEMの費用なし。すべてがオープンソースか自社開発です。
บทความเกี่ยวกับ SOC ส่วนใหญ่มักอธิบายสถาปัตยกรรม แต่บทความนี้จะพาไปดูเหตุการณ์จริงทีละ alert บน stack ที่ใช้งานจริงกับลูกค้าองค์กรขนาดกลาง — Wazuh สำหรับตรวจจับ, DFIR-IRIS สำหรับบริหารเคส และ integrator แบบ FastAPI ที่พัฒนาเองเชื่อมทั้งสองระบบเข้าด้วยกัน ไม่มีค่าไลเซนส์ SaaS ไม่มีค่า cloud SIEM ทุกส่วนเป็นโอเพนซอร์สหรือพัฒนาขึ้นเอง
Most SOC content explains architecture. This one walks through an actual incident, alert by alert, on a production stack running for a mid-sized enterprise client — Wazuh for detection, DFIR-IRIS for case management, and a custom FastAPI integrator holding the two together. No SaaS licenses. No cloud SIEM bill. Every component either open-source or built […]
