Articles › Security

第三方参与的数据泄露事件占比在一年内从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 […]

我接触的大多数安全团队都具备合理的IT卫生：端点部署了EDR、SIEM接入Windows事件日志，有时Web应用前还有WAF。但当我问到工厂车间在运行什么时，答案通常是"西门子S7、三菱SCADA，说实话我们也不完全清楚还有什么"。

私が話をするセキュリティチームの多くは、それなりのITハイジーンを持っています。エンドポイントにEDR、WindowsイベントログをインジェストするSIEM、WebアプリケーションにWAF。ところが、工場フロアで何が稼働しているかを聞くと、返ってくる答えはたいてい「Siemens S7と三菱のSCADA、あとは正直よく分からない」というものです。

ทีม Security ส่วนใหญ่ที่ผมคุยด้วยมี IT Hygiene ที่ดีพอสมควร: EDR บน Endpoint, SIEM ที่รับ Windows Event Log, บางทีมี WAF หน้า Web App ด้วย แต่พอถามว่าในสาย Production มีอะไรรันอยู่บ้าง คำตอบมักออกมาในแนว "Siemens S7, Mitsubishi SCADA แล้วก็… ไม่แน่ใจว่ามีอะไรอีก"

Most security teams I talk to have reasonable IT hygiene: EDR on endpoints, a SIEM ingesting Windows event logs, maybe a WAF in front of the web apps. Then I ask them what’s running on the factory floor and the answer is usually some variation of "Siemens S7s, a Mitsubishi SCADA, and honestly we’re not […]

大多数企业不会意识到自身存在身份管理问题——直到安全事故发生之后。 离职员工的账户仍在三个系统中保持活跃，因为没有人更新离职操作清单。某外包人员能够访问财务门户，因为六个月前申请了"临时"访问权限，工单从未关闭。一次网络钓鱼攻击得逞——不是因为安全防护薄弱，而是因为团队在管理24套独立的登录系统，没有人注意到其中一个根本没有启用MFA。

ほとんどの企業は、セキュリティ侵害が起きるまで自社のアイデンティティ問題に気づきません。

บริษัทส่วนใหญ่ไม่รู้ว่าตัวเองมีปัญหาด้านการจัดการตัวตนดิจิทัล — จนกว่าจะเกิดเหตุ บัญชีพนักงานที่ลาออกยังค้างอยู่ในสามระบบ เพราะไม่มีใครอัปเดต Checklist การปิดบัญชี ผู้รับเหมาได้สิทธิ์เข้าถึง Portal ฝ่ายการเงิน เพราะต้องการสิทธิ์ "ชั่วคราว" เมื่อหกเดือนก่อนและไม่มีใครปิดใบงาน การโจมตี Phishing สำเร็จ — ไม่ใช่เพราะระบบรักษาความปลอดภัยบกพร่อง แต่เพราะทีมไอทีต้องดูแลระบบล็อกอิน 24 ระบบแยกกัน และไม่มีใครสังเกตว่าระบบหนึ่งไม่มี MFA

Most companies don’t discover their identity problem until after the breach. A departing employee’s account stays active in three systems because nobody updated the offboarding checklist. A contractor gets access to the finance portal because they needed "temporary" access six months ago and the ticket was never closed. A phishing attack succeeds not because your […]