Articles › Security

安全日志中任何一个攻击者能够影响的字段，都是攻击者能够"写入"的字段。主机名、用户名、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 […]

大多数工程团队都有同一个心照不宣的漏洞：身份管理是所有人的问题，却是没有人负责的问题。以下是CTO和工程管理者如何解决这一问题，以及他们从中获得了什么。

多くのエンジニアリング組織が同じ無言の脆弱性を抱えています。アイデンティティはすべての人の問題でありながら、誰の責任でもない状態です。CTOやエンジニアリングマネージャーがこの問題をどう解決しているか、そして何を得ているかをご説明します。

องค์กรวิศวกรรมส่วนใหญ่มีจุดอ่อนที่ไม่ค่อยมีใครพูดถึง: เรื่องของ identity เป็นปัญหาของทุกคน แต่ไม่มีใครรับผิดชอบโดยตรง ต่อไปนี้คือวิธีที่ CTO และผู้จัดการฝ่ายวิศวกรรมกำลังแก้ไขปัญหานี้ และสิ่งที่พวกเขาได้รับจากการดำเนินการดังกล่าว

Most engineering organisations share the same unspoken vulnerability: identity is everyone’s problem and no one’s responsibility. Here is how CTOs and engineering managers are fixing it — and what they gain in the process.